> 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.
-- Daniel Taylor Senior Test Engineer Digi International danielt@digi.com Open systems win.
- 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/