Date: Wed, 28 Feb 2001 02:01:15 +0000 From: Brian Somers <brian@Awfulhak.org> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Drew Eckhardt <drew@PoohSticks.ORG>, David Rufino <daverufino@btinternet.com>, hackers@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: character device driver Message-ID: <200102280201.f1S21Fn01559@hak.lan.Awfulhak.org> In-Reply-To: Message from Robert Watson <rwatson@FreeBSD.ORG> of "Mon, 19 Feb 2001 00:22:57 EST." <Pine.NEB.3.96L.1010219001444.56503S-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[.....]
> 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.
IMHO phk's recent suggestion on -arch was excellent.
The idea is that a driver calls make_dev() with some sort of CLONE
flag. When a lookup() happens and devfs sees that the path points to
such a device, it asks the driver for a udev_t. The driver may (if
it wants to) call make_dev(), and then returns the udev_t. devfs
creates the vnode and returns it to the caller. The VOP_OPEN then
happens as usual. (I'm not sure what magic devfs needs to do with
the nameidata at this point).
The good thing about this is that the driver gets to declare a minor
as being a CLONE device and gets to choose whether it'll return a new
minor or not for the imminent open(). fork(), exec() and dup*() will
make new references to the same vnode, as will open()s of the device
if the driver did a make_dev(). Some sort of locking will be
required so that the driver can handle udev_t requests while others
are outstanding...
I'd like to implement something (if I ever get the time) and post
patches to -arch & phk, as this seems to solve all the problems I
know of :-)
> Robert N M Watson FreeBSD Core Team, TrustedBSD Project
> robert@fledge.watson.org NAI Labs, Safeport Network Services
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
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?200102280201.f1S21Fn01559>