Date: Mon, 19 Feb 2001 00:22:57 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Drew Eckhardt <drew@PoohSticks.ORG> Cc: David Rufino <daverufino@btinternet.com>, hackers@FreeBSD.ORG Subject: Re: character device driver Message-ID: <Pine.NEB.3.96L.1010219001444.56503S-100000@fledge.watson.org> In-Reply-To: <200102182317.f1INHTn24123@chopper.Poohsticks.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Feb 2001, Drew Eckhardt wrote: > In message <20010213193150.A882@btinternet.com>, daverufino@btinternet.com writ > es: > >Hi, > > > >I'm writing a character device driver in which each minor device can be > >opened more than once. When a device is opened is there a way to associate > >some private data for each opened instance ? > > As other people have noted, not in the general case. > > The solution I've used is to split the device minor number into a > physical unit and open instance part. You keep the existing per-unit > structure, and add per-instance data including a busy flag which causes > opens to return EBUSY. In your user land application, you iterate over > the devices in round-robin fashion as long as you get back EBUSY as you > would for pty masters. There are been a number of discussions at various points about ways to introduce statefulness to VFS layers and the interface with the device code in specfs. My current favorite is to introduce statefulness at the VFS layer where sessions are created during vop_open() by adding a cookie pointer passed by reference to VOP_OPEN(). The vnode implementor can, if non-NULL was passed in, optionally return cookie information (a void *) which is held in the struct file and then passed into other VOP's associated with the open file. When VOP_CLOSE is called (when the struct file refcount hits 0), the session is terminated. For file systems not supporting stateful access, the cookie would simply be null; some VOP's (such as getattr, etc) would not care about state. But for those that did, the state information could be propagated down to the device open/close calls, which could now be bound to sessions, meaning that opens and closes would have the opportunity to pass their own cookie up to VFS (presumably to be stored in the VFS state), meaning that device accesses could be associated with state, and there would by symetric opens and closes on devices also. Another possibility here is the linux route, which passes the struct file down the VFS stack allowing the device to use the struct file to maintain state (I'm not sure of the details, but believe the Linux vmware driver uses this). In my mind, it is important that (in the general case) we provide a struct file state hook rather than having per-process state, to allow things like threads, process teams, aio, file descriptor passing, etc, to work properly. One advantage to tying VFS statefulness to device statefulness is you get some nice benefits like guarantees about open/close pairs on devices. I think there aren't too many VFS complications -- the only complications might be if vnodes are ever used for relevant calls (ioctl, read, write, ...) without a VOP_OPEN first -- a few used to exist but I think those have been cleaned up. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010219001444.56503S-100000>