Date: Sat, 10 Feb 1996 05:17:47 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: current@freebsd.org Subject: devfs persistence (was FSP:TNG) Message-ID: <199602101017.FAA09487@hda.com> In-Reply-To: <23357.823938528@time.cdrom.com> from "Jordan K. Hubbard" at Feb 9, 96 11:48:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I *strongly* disagree with you. If I change the dev's on my firewall > > I expect 'em to damn well stay changed and the first time they don't > > I first go searching for the person that hacked the firewall, then > > finding nothing, I dump it and rebuild it from scratch assuming that > > I've just been badly beaten at my game. Now you tell me that they won't > > stay that way? I dump it and get a new o/s. > > FWIW, this is almost word-for-word what the folks at USENIX told me > and Julian will almost certainly never convince me that this is a > problem that can be dismissed lightly. I will fight long and hard for > compatibility because I happen to think that I'm 100% right about how > users will feel about this, and if no one else will speak for them, > I will. My first question about Julian's devfs was how it lasted across reboots (and the answer was an rc answer at the time). I think it again points toward a second boot file that stores configuration - after all, in addition to devfs you want to store away which drivers to lkm in - they are coupled. This is (IMHO) flatly a requirement on devfs. It has to work the same way as it does now as well as any new way. -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602101017.FAA09487>