From owner-freebsd-hackers Tue Feb 27 18:11:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 92F0937B718; Tue, 27 Feb 2001 18:11:46 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1S1xX455382; Wed, 28 Feb 2001 02:00:48 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1S21Fn01559; Wed, 28 Feb 2001 02:01:15 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102280201.f1S21Fn01559@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Robert Watson Cc: Drew Eckhardt , David Rufino , hackers@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: character device driver In-Reply-To: Message from Robert Watson of "Mon, 19 Feb 2001 00:22:57 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Feb 2001 02:01:15 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > 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 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