On Thu, 16 Aug 2001, Greg Lehey wrote:
> On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote:
> > In message <[EMAIL PROTECTED]>, Greg Lehey writes:
> >> In view of the fact that this thread is about deficiencies in your
> >> devfs, this is particularly uncalled for. One of the reasons that
> >> Julian's devfs never got debugged was that you had made it very clear
> >> from the start that it would be removed.
> >
> > History being rewritten eh ? I spent 3+ years trying to argue his
> > DEVFS should be made default!
>
> They must have been before I met you, then. My very vivid
> recollection was that I met you at USENIX in New Orleans on 19 June
> 1998, and the very first thing you said was "What does Vinum do about
> DEVFS? Don't use it, it's going away". We (you, Justin Gibbs,
He first sold it to me on Tue, 6 Dec 1994 15:41:55 -0800 (PST). It
seemed like a good idea at the time :-). That sure was a different
time. ref but no freefall (?)...
> From [EMAIL PROTECTED] Wed Dec 7 10:45:03 1994
> Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by godzilla.zeta.org.au
>(8.6.9/8.6.9) with ESMTP id KAA24274 for <[EMAIL PROTECTED]>; Wed, 7 Dec 1994 10:42:08
>+1100
> Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id PAA10093; Tue, 6 Dec
>1994 15:41:55 -0800
> From: Poul-Henning Kamp <[EMAIL PROTECTED]>
> Message-Id: <[EMAIL PROTECTED]>
> Subject: Re: vn.c,v
> To: [EMAIL PROTECTED] (Bruce Evans)
> Date: Tue, 6 Dec 1994 15:41:55 -0800 (PST)
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> In-Reply-To: <[EMAIL PROTECTED]> from "Bruce Evans" at Dec
>7, 94 09:50:43 am
> Content-Type: text
> Content-Length: 4320
> Status: RO
>
> > >I really miss these functions in the kernel:
> >
> > > void * dev_get_private __P((dev_t));
> > >...
> > >I talked to Julian about his "devfs" and the above changes might be fallout
> > >from that when all is said and done.
> >
> > I don't see how you can access the devices without putting them in the
> > file system. How complete is devfs? How can it handle all the different
> > meanings of minor numbers? Things like ttyd0 vs cuaa0 probably should
> > use different majors anyway.
>
> I'm terrible at explaning this stuff, but I will do an attempt now. If
> this looks like complete rubbish to you, then I probably didn't explain it
> too well, and have better try again.
>
> I have cc'ed the arch list on this, as well as Julian, since it came out
> to be quite a general description.
>
> The "devfs" idea is to implement a filesystem, where the devices present
> reflect what the device-drivers told us that they have found, without having
> to much around with MAKEDEV,mknod,cdevsw and bdevsw.
>
> So for instance, the fd driver probes and finds a 720 Kb 3.5" drive it would
> call something like
>
> /* /dev/???, major, minor */
> devfs_register("fd0", 2, 0);
> devfs_register("fd0.360", 2, 8);
> devfs_register("fd0.720", 2, 7);
> ...
>
> (Of course the "fd0" string would need to be built dynamicly somehow, and
> probably we should apply some kind of '%' escapes to help do so)
>
> And the entries will show up in /dev because the devfs maintains a table
> "fd0" <--> (2,0)
>
> Pow! there goes mknod and MAKEDEV.
>
> The devfs doesn't interpret the dev_t's it only maintains the
> /dev/foo -> dev_t association.
>
> Doing it this way, the entire concept of major/minor numbers can
> be dropped from the plan, because a dev_t could just as well be a "void *"
> now.
>
> By having the devfs take care of the registration, the cdevsw/bdevsw
> got obsolete, because the device-drivers themselves know their names now,
> and the major/minor was only a way to pass information from mknod to the
> driver.
>
> This means that a device-driver could register it's "softc" structure
> directly with the devfs, instead of having to look up from the dev_t first.
>
> To make it convenient, we would make the dev_t this instead:
>
> typedef struct {
> char *d_name;
> struct driver *d_driver;
> void *d_private_1;
> unsigned long d_private_2;
> } * dev_t;
> #define dev_private1(dev) (dev->d_private_1)
> #define dev_private2(dev) (dev->d_private_2)
> #define dev_name(dev) (dev->d_name)
>
> and the register would look like this in fd.c:
>
> /sys/sys/something.h:
>
> struct dev_driver {
> char *dev_name;
> int (*dev_open) __P((...));
> int (*dev_close) __P((...));
> int (*dev_ioctl) __P((...));
> ...
> }
>
> fd.c:
> /* this is in global scope */
> static struct dev_driver {
> "fd",
> fd_open,
> fd_close
> ...
> } fd_driver;
>
> /* Ha! we found a drive */
> fsc = malloc (sizeof struct fd_softc, M_DEVBUF, M_WAITOK);
> fsc->foo = this;
> fsc->bar = that;
> ...
> /* /dev/???, private_1, private_2 */
> devfs_register(fd_driver, "fd0", fsc, 0);
> devfs_register(fd_driver, "fd0.360", fsc, 350);
> devfs_register(fd_driver, "fd0.720", fsc, 720);
> /*
> * We probably need the (char/block) distinction still so add
> * a enum argument for that...
> */
>
> Now when fdstrategy is called it would do
>
> struct fd_softc *fsc = dev_private1(bp->b_dev);
> int mode = dev_private2(bp->b_dev);
>
> And a little later when it found a problem:
> printf("%s: Punchcards only supported on sundays\n",
> dev_name(bp->b_dev));
>
> So when you do a:
> tar tvf /dev/rfd0.720
>
> The open("/dev/rfd0.720") finds it's way to the devfs, which resolves
> it to a "S_IFCHR" and it has this dev_t associated with it. That
> dev_t can be used to find the fd_open like this:
> error = (*this_dev_t->d_driver->dev_open)(this_dev_t, flags);
>
> and fdopen, can find the soft_c structure from the dev_t argument:
>
> struct fd_softc = dev_private1(dev);
> int type = FDTYPE(dev_private2(dev));
> ...
>
> You see ? no more mknod, no more cdevsw/bdevsw, no more minor() and major().
> A device is described by the dev_t, and if you need more than a (void *) and
> a u_long to select your device, then I'll happily throw in another 32 bits
> for you :-)
>
> like it ?
> --
> Poul-Henning Kamp <[EMAIL PROTECTED]>
> TRW Financial Systems, Inc.
> FreeBSD has, until now, not one single time had an undetected error. :-)
>
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
