Date: Tue, 25 Jul 2000 14:13:49 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <Pine.BSF.4.05.10007251407451.16927-100000@semuta.feral.com> In-Reply-To: <14391.964559237@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm not sure allowing spaces is a good idea, so maybe they should > just silently be turned into underscore. Drive serial numbers are, sigh, ASCII strings with spaces..... Personally, I'd like to see the name more strongly defined. We already require in fstab a strong definition of what the content is (filesystem type 'zot'). We require a mount point. We have an inadequate but strong definition of the device to associate with the mount point with the filesystem of type 'zot'. I'd propose that the device definition could be fuzzier but still needs defined selectors to avoid overlap and chaos. > >This does fit more with a real devfs tho.... > > Right, it sure does. > > I don't know if you followed some of the recent discussions about > DEVFS, but one of my ideas is that cloning be implemented so that > if the DEVFS doesn't find the name somebody tries to namei(), it > will poll a list of driver functions (registered by the drivers) > and if any of the drivers can instatiate the requested name they > do so and the lookup succeeds from there. > > Doing it that way with a devfs means that you could actually > open /dev/HW:BLABLA and if the cam driver recognized this as > it's cue to examine the SCSI serial numbers it would do so > and if it found one matching it would instantiate the device > and your open would succeed. > > The advantage to that scheme is that we don't clutter /dev > with 7 different names for each disk, only the names people > try to open are present. Hmmmmm ... Ehrrmmmm.... Ummm..... Okay- then you'll get the same feel as the automounter gives when you do an ls of '/net/freefall.freebsd.org'- a bit of a hang as this occurs and requires any actual probing. This better only be done via a policy setting. Otherwise, the devices have to return their last 'best information' about whether they can get at that device. -matt 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?Pine.BSF.4.05.10007251407451.16927-100000>