Date: Fri, 9 Feb 1996 12:20:09 -0800 (PST) From: Julian Elischer <julian@ref.tfs.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, current@freebsd.org Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <199602092020.MAA00264@ref.tfs.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 :) > I'm joking until I figure a way around the persistance problem personally I'll be using a kernel that will disable the use of devices on all kinds of filesystems other than devfs. Actually I think persistance is not a real problem, it's a PR excersize We're getting creamed by NT which doesn't have permissions persistance. I think a utility that allows the admin to tune the permissions of devices will make the screams go away. basically a little menu system similar to what you use in the install system. as output it produces a littel file called devs.rc that is run at boot. > 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. and I notice none of them really came up to ME and discussed it except for charles and CGD. I think it's one of thos things that they'll scream about then forget. There are a few possible things that can be done, e.g. union mounting devfs with the root disk and reading through only the permissions. but most of them are UGLY. I think I'm going to have to write the menu app before people believe me about this.. > > 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. I disagree about this. > 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. I think that is vastly overstating the problem. The more I think about it the more I think that it's not a problem. I think they'd have the same reaction if they went to AUS and discovered that handguns were illegal. They'd complain if their mothers cleaned up their bedrooms. I'd suggest a seprate utility to allow this to be done REALLY EASILY. One possibility I thought about was a user-land daemon that scans the directory every now and then (cron?) and notices changes.. alternatively there could be syslog option to send messages from the device filesystem out to some sort of log that get's replayed on bootup. I personally don't think it's a problem except in the minds of those who are stuck in the past. Things need to change. 1/ major numbers need to become dynamic 2/ devices shouldn't exist without their /dev/entries 3/ devices shouldn't exist with the WRONG /dev/entries 4/ /dev/entries with no corresponding device is also bogus 5/ minor numbers need to become dynamic for some device types 6/ devices need to be able to change their representation on the fly given this I don't see how there can be another answer, except for something that can pass through the sysctl interface and pull out all the minor numbers. That would be I think an ugly answer but one some-one else is welcome to try. Anyone who wants full persistance is welcome to use the old system and try work out what minor numbers are valid for the disk slices on the fly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602092020.MAA00264>