Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!news.msfc.nasa.gov!sol.ctr.columbia.edu!startide.ctr.columbia.edu!wpaul
From: wpaul@ctr.columbia.edu (Bill Paul)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: New Install / Observations & Gripes
Date: 8 Jan 1996 18:55:50 GMT
Organization: Columbia University Center for Telecommunications Research
Lines: 153
Message-ID: <4crpbm$hja@sol.ctr.columbia.edu>
References: <DKup49.M1t@bnr.ca> <4cqk44$3gt@agate.berkeley.edu>
NNTP-Posting-Host: startide.ctr.columbia.edu
X-Newsreader: TIN [version 1.2 PL2]
Daring to challenge the will of the almighty Leviam00se, Jordan K. Hubbard
(jkh@violet.berkeley.edu) had the courage to say:
: In article <DKup49.M1t@bnr.ca>, Barry Friedman <friedman@bnr.ca> wrote:
: >First of all my cdrom is on a soundblaster which had it's port address
: >set to 0x340 which defaulted to mcd1 instead of mcd0. So my first reaction
: >to the install procedure which was "WOW - this is a SYSTEM!" (After
: Yeah, I know, this is a pain.
: Just by way of explanation, the original intention was indeed to enable
: sysinstall to recognise *either* mcd1 or mcd0 (or scd0/scd1, matcd0/matcd1,
: etc) and I did quite a bit of work to allow this to function, but disaster
: struck when I ran out of inodes on the boot floppy and I wasn't able to
: include the *friggin' device entries* for all the potential 2nd CDROM
: controllers in /dev! :-( Since sysinstall does very crude "device detection"
: by basically trying to see which devs it can open and which it can't
: (the devinfo stuff also not being ready for prime-time :-( ), this sunk
: me. The kernel finds it, it's there, I just don't have a device entry to
: talk to it. I'm basically waiting for devfs to save our necks here
: and divorce device entries from inodes.
*screeech!*
Uh.... wait a minute. (*sound of Bill rummaging around for his soapbox
and fire-retardant jockey shorts*)
This is gonna come of sounding really pissy and whiny, but I have
to say it and I can't find any better way to do it: I am sick and
tired of hearing how devfs is going to save the world. It's not even
finished yet and everybody's still talking about like it's the greatest
thing since penicillin. I'm not trying to knock the people working
on it and I'm not trying to be a crotchety old traditionalist stick
in the mud (well, maybe a little -- old habits die hard), but it really
bugs me when I see people touting a sexy new innovation as the solution
to everyone's worries when there's already a perfectly good (and working)
innovation sitting right under their noses that can solve the problem
just as easily. (Must be my EE showing: I keep thinking of 'path of least
resistance' and all that.)
Devfs is not the only way to solve this problem: there's already a
mechanism in place that seems perfectly suited to this sort of task:
it's called devconf (and don't you dare tell me that devconf will
be "going away soon" -- I mean it: I'll scream). Lemme illustrate
so I don't seem like a total looney:
The problem here is that there aren't enough inodes for all the possible
devices that are needed to make sysinstall work: you don't have room for
all the CD-ROMS and all the SCSI and IDE disks and all the tape drives,
and all the serial ports, and so on.
Okay, fine.
But I'll bet you do have enough to just get sysinstall off the ground
and still have some left to spare. Right?
In that case, you could do this:
1) When building the boot floppy, make just the nodes for devices that
are mandatory or that you know will be there: ttys, console, mem,
kmem, floppy and maybe one or two other sundries. Leave enough inodes
free for the devices you expect to find in the future: figure at
least two disks, a CD-ROM, a tape drive and maybe another floppy
drive. Network interfaces don't require inodes in BSD so you're
safe there (except for serial ports for SLIP/PPP).
2) After the boot floppy boots, make sysinstall do what lsdev does:
use sysctl() to query all the devconf information from the kernel.
lsdev doesn't need any device nodes to figure out what devices are
present in the system: each physical device is supposed to register
itself with devconf when its attach routine runs. You get oodles of
device informarion all for the price of just one thin system call.
3) Once sysinstall knows where all the devices are, it can mknod()
the required device nodes on the fly all by itself. Presto! You
have a dynamically configured /dev directory for your installation
with only the device nodes that you need. You don't even have to
create them all at once: if it happens that a user has many devices
and there isn't enough room to create them all, then just create
the ones you need for a given operation, then erase them, then make
the ones you need for the next operation, erase them, and so on.
Advantages:
- The stuff you need to do it is already in the kernel just waiting
to be used. In fact this is probably the first time anyone's even
thought about using devconf for anything meaningful. (Okay, it's the
first time _I've_ thought about it.)
- Wouldn't involve massive and possibly bug-inducing structural changes
to the guts of the kernel. (Call me crazy, but I like stability more
than I like innovation.)
- Shouldn't take too much additional coding to make sysinstall handle
this: you could steal much of the work from lsdev.
- Would motivate people to finally make all the device drivers devconf
compliant.
#ifdef FRIVOLOUS_RELIGIOUSLY_MOTIVATED_RANTING
- It's more BSDish than devfs. ("Welcome to all things BSDish! If it's
not BSDish, it's crap!")
#endif
Disadvantages:
- Some device drivers don't register themselves with devconf like they're
supposed supposed to (for instance: the matcd driver (FDIV? Are you
listening?), the Voxware sound drivers, the PS/2 mouse driver, and
probably others).
HOWEVER: It wouldn't take that much work to make them all behave, and
you could do it long before devfs is ready for prime time.
- Device entries still won't be divorced from inodes.
HOWEVER: Er... yeah? So?
- It's my idea, and I'm a card-carrying, government-certified idiot.
HOWEVER: I'm not alone. :)
- Uh... well, at least where this particular problem is concerned, I
can't think of any more, though if someone else can, feel free to
speak up.
Now, if this idea has been considered and shot down already, then I
can accept that, though I'd be interested to know why. If it hasn't
already been considered, it should be. I can't be the only person who's
thought of this. It's too obvious. (Besides I know I'm not the only
idiot around here. :)
Granted, this is only the solution to one problem. I know that people
want devfs for more than just taking some of the sting out of the
installation processes. But I'm still not convinced that it's really the
cureall that everybody says it is, and there's certainly an alternative
available here.
Alright alright: I'm climbing down off the soapbox already... Geeze:
the slings and arrows are getting bigger every year.
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
License error: The license for this .sig file has expired. You must obtain
a new license key before any more witty phrases will appear in this space.
=============================================================================