Re: USB device allocation

Martin Dalecki (dalecki@cs.net.pl)
Wed, 06 Oct 1999 20:06:55 +0200

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/