From owner-freebsd-current Thu Aug 16 6:56:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id CE32D37B407; Thu, 16 Aug 2001 06:56:37 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA05299; Thu, 16 Aug 2001 23:56:31 +1000 Date: Thu, 16 Aug 2001 23:56:30 +1000 (EST) From: Bruce Evans X-X-Sender: To: Greg Lehey Cc: Poul-Henning Kamp , Julian Elischer , Andrew Kenneth Milton , Michael Lucas , Subject: Re: devfs deficiencies (was: devfs and Vinum (was: any -current && vinum problems?)) In-Reply-To: <20010816173613.C15022@wantadilla.lemis.com> Message-ID: <20010816234458.D28977-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 16 Aug 2001, Greg Lehey wrote: > On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote: > > In message <20010816094735.F49989@wantadilla.lemis.com>, 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 phk@ref.tfs.com 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 ; 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 > Message-Id: <199412062341.PAA10093@ref.tfs.com> > Subject: Re: vn.c,v > To: bde@zeta.org.au (Bruce Evans) > Date: Tue, 6 Dec 1994 15:41:55 -0800 (PST) > Cc: julian@tfs.com, arch@freebsd.org > In-Reply-To: <199412062250.JAA23711@godzilla.zeta.org.au> 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 > TRW Financial Systems, Inc. > FreeBSD has, until now, not one single time had an undetected error. :-) > Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message