Date: Wed, 2 Apr 1997 10:24:17 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, nate@mt.sri.com, proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: Internal clock Message-ID: <199704021724.KAA13803@phaeton.artisoft.com> In-Reply-To: <28836.859954625@time.cdrom.com> from "Jordan K. Hubbard" at Apr 1, 97 08:17:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have *no* idea what is preventing you from making it the default > > mechanism. > > 1. It has no persistance and a number of people have already told me directly > (some of them at USENIX, immediately following Julian's talk on DEVFS) > that we will be roundly castigated and screamed at in the various > public forums for breaking /dev's historical behavior if we don't make > persistance work and work *completely transparently*. Let's say > somebody has a "securify" script that they run on a new system as part > of their security auditing process. It's been running on FreeBSD > systems since 2.0, making sure that tape drives and CDROMs and such > all have sane perms (or maybe even some sort of "insane" perms which are > part of a more elaborate ownership scheme which they like), and now > suddenly with FreeBSD 4.0 or whatever they find that everything the > script does on these new systems is undone after a reboot. Say what?? > > Sure, one can stick something in /etc/rc.local which does everything > from beating on /dev to translating the catpages into Urdu, but > the fact remains that someone shouldn't need to do that. As you yourself > say, things should stay *backwards compatible*. :-) Frankly, I don't care about persistance other than the default permission, which should be set correctly already so that most everyone besides me doesn't care about persistance either. As far as putting code into rc.local & rc.shutdown: why doesn't that count as transparent? Because we can't upgrade the rc scripts out from under people because we haven't provided sufficient abstraction of the data representing the configuration from the code that implements it? That brings us to the other thing I have no idea why it hasn't been integrated: directory based rc processing for per configuration item scripts. It doesn't matter if you replace only the rc components that you control by default anyway, as long as you can do so without damaging third-party and post-install configuration. It seems to me that the same people whining for persistance of non-default settings that they aren't willing to set in the device registration for the devices they want non-default should be whining for directory-based rc code. > 2. It tends to panic the system fairly regularly on steady use. Why on > earth would we make something this dangerous the default? It's > simply not finished yet, and there are numerous open PRs against it in > the PR database (#2033, #2034, #2738 and possibly #1211). These are generally on unmount. The ones that aren't, weren't there until there was implementation of this ill-concieved notion of supplying persistance in the devfs code instead of as an external elective for those people who wanted hacker changes to their system to survive reboot, for God only knows why. I keep telling everyone how to fix the VFS code, as I have for the past four (*4*) years (*YEARS*), and keep offering code, but it's always turned down as doing too much at once. The issues are in the layering of the VFS code, and how you define a VFS consumer (including a set of system calls). Now that I've scaled back the code into a "gee, a third grader could understand this"-sized pieces, it looks like something might happen (understandably, one third-grade mentality sized piece at a time is unlikely to implement all the necessary fixes at once). But if you are going to demand "a fix by Tuesday", you must be prepared to take a fix that is non-trivial and may take real effort to understand. Keep your eyes on your goal, not the obstacles, or all you will see is obstacles. Regards, 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?199704021724.KAA13803>