Date: Wed, 15 Jan 2003 13:43:41 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: phk@freebsd.org Cc: arch@freebsd.org Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. Message-ID: <15909.43997.980937.352619@grasshopper.cs.duke.edu> In-Reply-To: <17952.1042654440@critter.freebsd.dk> References: <15909.41869.176059.969484@grasshopper.cs.duke.edu> <17952.1042654440@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
phk@freebsd.org writes: > In message <15909.41869.176059.969484@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: > > > > >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? > > > > > > There are a number of ways to do this, none easy (IMO). > > > > > > I understand what you want, but I don't think we can credibly claim > > > to get this into any working shape for 5-stable. > > > >I obviously don't know this code as well as you do, but I'd think > >that adding a 'struct file *fp' pointer to the list of args > >that the various vops take would be all thats needed. What am I > >missing? > > "all the details" ? :-) ;) > There are a fair number of issues in this area that needs addressed, > this is just one of them. Doing things right here will take more > than a couple of months time (incl. testing), > > And without address to anybody in particular: it should not be done > in a few hours time by some "HeldenHacker" who think this is trivial, > there is a whole host of locking issues related to semi-magic devices > like /dev/fd/* and similar which needs careful thought. Hmm.. I don't propose actually converting existing drivers to use the new interface, I agree that would be very tricky and time consuming, and would require extensive testing. What I was proposing is to just push the struct file * down to open/close/ioctl/* for new drivers, and to do the conversion of existing drivers lazily. Old drivers get to add another arg they don't use to their open/close/ioctl/* functions. (mmap is a little different -- you need to make the opaque handle into a file pointer..) 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.43997.980937.352619>