Date: Sat, 2 Aug 1997 12:22:18 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jas@flyingfox.com (Jim Shankland) Cc: luigi@labinfo.iet.unipi.it, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: device close behaviour - a question Message-ID: <199708020252.MAA08782@genesis.atrad.adelaide.edu.au> In-Reply-To: <199708011655.JAA03079@biggusdiskus.flyingfox.com> from Jim Shankland at "Aug 1, 97 09:55:15 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Jim Shankland stands accused of saying: > [Luigi Rizzo would like his audio driver to be notified every time > the device is closed, not just on last close.] > > The way I've dealt with a similar situation in the past is to represent > each physical device as an array of minor device numbers, on each of > which the driver enforces an exclusive-open. User-level code must The point I am trying to make here is that you _cannot_ enforce an exclusive open, because the devic driver is not notified under all of the circumstances which result in a new fd being granted. > then iterate over the devices, until an open() call does not return > EBUSY (just like looking for an available pty). Since each "device" > is open at most once, the device_close() routine gets called on > every user-level close() call. This scheme works well if you are at liberty to enforce the behaviour of userland programs. Luigi is faced with remaining compatible with previous versions and also with the Linux interface, which is a fairly crippling requirement in and of itself. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708020252.MAA08782>