From owner-freebsd-hackers Sat Aug 2 20:17:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA01125 for hackers-outgoing; Sat, 2 Aug 1997 20:17:29 -0700 (PDT) Received: from www2.shoppersnet.com (shoppersnet.com [204.156.152.112]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA01118 for ; Sat, 2 Aug 1997 20:17:26 -0700 (PDT) Received: (from hlew@localhost) by www2.shoppersnet.com (8.8.5/8.8.5) id UAA28022; Sat, 2 Aug 1997 20:20:45 -0700 (PDT) Date: Sat, 2 Aug 1997 20:20:45 -0700 (PDT) From: Howard Lew To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: device close behaviour - a question In-Reply-To: <199708010302.FAA06838@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I had a chance to play around with the sound code. I like the driver documentation a lot. Is the guspnp14 stuff much different from Luigi's snd970726 code? Hmmm... Is the isa_dmastatus really used at this point? I looked around the isa code trying to patch it up to compile, but I couldn't find a function related to it. Or was this the question below? > > I am having a problem related to the having multiple (actually, > 2) open descriptors on the same character device. More specifically, > I notice that only the last close does actually invoke the device > close routine. > > >From the code in /sys/miscfs/specfs/spec_vnops.c, function > spec_close(), this behaviour seems intentional. But can someone > explain why this is done and where this is useful ? > I do not dare to suggest that this be changed since I guess it would > break many things... or not ? > > In my case, I have implemented the ability of having up to two open > descriptors on full-duplex audio devices, one for read and one for > write. The above behaviour does not let me record that a channel > has been freed (this I would have done using the close() call), > and complicates life to the driver since it has to guess what is > happening. > > I do have locks on concurrent operations of the same type, and have > implemented some hacks to (more or less) control that proper device > usage is done. However, these are hacks, and the lack of information > can cause suboptimal behaviours. As an example, due to the missing > close I cannot decide to stop a DMA read since I don't know if the > reading process has gone. > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ > --------------------------------------------------------------------------- Shoppers Network (Support) AMD K5/K6s, Cyrix 6x86, Intel Pentiums/Pro Phone: (415) 759-8584 Email: howard@shoppersnet.com ==============================> WWW - http://www.shoppersnet.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~