Date: Fri, 9 Feb 1996 09:13:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: julian@ref.tfs.com, terry@lambert.org, current@freebsd.org Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <199602091613.JAA10469@phaeton.artisoft.com> In-Reply-To: <19888.823871509@time.cdrom.com> from "Jordan K. Hubbard" at Feb 9, 96 05:11:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > hmm but devfs might be compulsory :) > > Erm.. I know you're probably joking, but since you bring it up. I > don't think that we should even ever consider making devfs mandatory > (optional is fine, I don't mind optional) until a persistance > mechanism that's fully transparent to the user is implemented. > > I had UNIX old-timers walk up and tear *my* ears off over this after > Julian's talk at USENIX - they were not at all pleased by his answer > that he considered persistance "a user problem" :-) However, their > impassioned diatribes did give me a chance to consider the matter of > persistence more fully myself, I have to say that I find myself more > or less in full agreement with them. > > It has to work the way it works now, e.g. you should be able to just > walk into /dev (and that could be one of many incarnations of `dev', > remember) and futz with permissions or "delete" device entries you > don't want to be present for security reasons, and that information > should stay there across mounts. David, Justin, Sean and I stood > around for awhile thinking of some ways this might be done in a log > file somewhere, and I'm sure the problem isn't insurmountable. To NOT > do this and force our users to have to specifically edit chmod, mknods > or rm commands into /etc/rc in order to preserve their changes to /dev > across reboots, well, the phrase "a serious public reaming" comes to > mind when I contemplate the outcome. Entry deletion does not make sense. Not if you keep the ability to mknod on other devices (like NFS devices). The ability to make devices for which there are not drivers does not make sense either. The ability to add hard links, and the ability to add symlinks, etc., is another matter. Not to get into a discussion of what should be allowed to persist and what shouldn't, or where in the shutdown/reboot process this information should be saved and where in the boot process it should be restored... But it's clear to me, and it should be clear to everyone else, that specfs must die. For netbooting, a mounted /dev that is not an export of the device space for a kernel boot instance is plain broken. FreeBSD already uses too many manjor/minor bits for hosting on SunOS, and it's only going to get worse as feature-add falls in. There is also the administrative problems of external developers. I'm a big example of that, since I tend to have changes coming in full-blown and therefore impacting a larger number of files. But this is also applicable to "Joe Schmoe" who wants a major device number for his driver because major device numbers are lexical indices in a fixed table that have to be synchronized with the MAKEDEV "utility" (and I use that term loosely). The more you can decouple external developers needs and auto-satisfaction of those needs from placing demands on the core team (a finite resource), the better off you will be. The process is not the product; it is *supposed* to be there to advance the product. Any time it gets in the way is an error. It's possible to, like the "boot -c" configuration saves, fix the problem of persistance with *automatic* rc file munging. The ability to do this automatically is probably one of the biggest arguments for an rc?.d (SYSV) or "rc.shutdown" (more BSD-like) extension to the system controls. I think that *not* requiring the implementation of the persistance facility (think netbooting, again) prior to deployment of a mandatory devfs is a *major* incentive to cause the feature to be added by the people who feel they need it. The lag on the developement of the ability to save "boot -c" data after "boot -c" was implemented was not an inherently bad thing. A mandatory devfs is a *MAJOR* win when it comes to porting to other platforms. I know that this is not the popular architectural overview in the FreeBSD camp, but don't condemn the idea because of its NetBSD origins. A good idea is a good idea, regardless of origin. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602091613.JAA10469>