Date: Fri, 09 Feb 1996 05:11:49 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Julian Elischer <julian@ref.tfs.com> Cc: terry@lambert.org (Terry Lambert), current@freebsd.org Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <19888.823871509@time.cdrom.com> In-Reply-To: Your message of "Tue, 06 Feb 1996 13:59:24 PST." <199602062159.NAA01076@ref.tfs.com>
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. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19888.823871509>