Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Aug 1997 05:02:11 +0200 (MET DST)
From:      Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To:        hackers@freebsd.org
Subject:   device close behaviour - a question
Message-ID:  <199708010302.FAA06838@labinfo.iet.unipi.it>

next in thread | raw e-mail | index | archive | help
Hi,

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/
_____________________________|______________________________________



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708010302.FAA06838>