Messages in this thread | | | Date | Wed, 06 Oct 1999 20:06:55 +0200 | From | Martin Dalecki <> | Subject | Re: USB device allocation |
| |
danielt@digi.com wrote: > > On Tue, 5 Oct 1999, H. Peter Anvin wrote: > > > David Weinehall wrote: > > > > > > > > > > Why is that? You get the same layout with a dynamic-filesystem; the > > > > > difference is that with dynamic devices it becomes FAR easier to support > > > > > plug'n'play devices. > > > > > > > > > > > > > You get persistence; because the /devices tree is augmented, but not > > > > blindly. > > > > > > That's what devfsd is for (persistance.) > > > > > > > Of course, once you have a daemon in userspace anyway, the kernel > > filesystem is just bloat. > > > Counterexamples: > Diskless workstations with USB (say an iMac that boots Linux from > the network to preserve the integrity of its MacOS install). > > Small embedded systems (the filesystem takes RAM anyway) > > Normal configurations and applications where persistance is *UN*desirable > and having the system restore default conditions on device > reinitialization is the right thing to do. > > Face it, most sane admins do not go mucking about with the > permissions and ownership of device files except in cases > where it is the best/only way to get the job done. > > It is too easy to lose notes or forget *why* you did the change, > and when you rebuild your environment you lose the changes. > So you didn't really have persistence anyway. > > The benefits of devfs so far outweigh the costs that I cannot > come up with a good reason not to _have_it_available_. > > I WOULD TRADE THE SPACE MY DRIVER TAKES UP IN THE ARCHIVE FOR DEVFS > IN THE KERNEL.
Yes and there it is again. The admins say: "What a wonderfull hack! there is a filesystem where I can echo 100000 > /proc/somemagic_file and manipulate this and that kernel behaviour. WONDERFULL! GIVE ME MORE I NEED devfs"
But anybody more concearned with system design sees this and says: "What a childisch idea. Files are data and file systems are for files and for nothing else. They shouldn't be abused as a backdoor to the kernel. It's violating nearly every abstraction underlying the overall system. It's twisted. It's ugly. It's infecting the code all over the places. (Oh yes Alan is busy hiding this be editing CONFIG_PROC out of places where it's needed...) Didn't they know that parsing numbers in ASCII is a mess? Why did they something like this instead of an appriopriate hierarichical syscontrol interface with accomplying user level utility programms? (Hey they could check for a magic interface version number on entry for example! What a luxus!) Such a design would be more separate from the rest of the system and could be made more robust since it wouldn't need to fit into any superfious file semantics emulation like fitting and elephant through a keyhole. And so on and so on, and therefore it would be by far more stable during further developement of the overall system... And now they are eager to introduce even more of this kind of stuff (Ahhh a tar cf blah /dev/* triggered from kernel level for persistency! WODERFULLL!). Ugh not too long in the future this all will be looking quite like the >Registry< just even worser becouse entierly inside the kernel. Ehh... And there is still the question how they will explain how this all is supposed to work to the first class students of this os? Oh yes they will be working on KDE level anyway..."
Oh maybe just doing it the boringly, stable probed way just wasn't sexy enough for "open source".
--Marcin
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |