Date: Wed, 15 Jan 2003 11:52:10 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Poul-Henning Kamp <phk@freebsd.org> Cc: arch@freebsd.org Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. Message-ID: <15909.37306.656490.486061@grasshopper.cs.duke.edu> In-Reply-To: <14715.1042634253@critter.freebsd.dk> References: <14715.1042634253@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Speaking of /dev, driver writers, and API/ABI decisions to be made before the 5.0-stable brach, I've got a minor axe to grind. Factory devices. Weren't you talking about changing the driver interface in such a way as to make factory devices easier to implement on FreeBSD? I would *love* to see this in 5.0-stable so that I don't have to support the clunky old way I came up with to handle it (conjuring a vnode out of thin air..) Or am I all wet, and its easy to do now? What I'm after is passing the struct file all the way down to open,close,ioctl,mmap,etc, and having a void * field in struct file that a driver can hang a softc pointer off of. That way an application can always open /dev/foo0 and not have to hunt around in the /dev namespace, looking for an unused minor /dev/foo299. The driver just looks at the struct file pointer it gets in ioctl for example, and isn't limited to the major/minor number of the underlying dev_t. This would be a real boon to people porting linux drivers (aka, vmware). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15909.37306.656490.486061>