Re: [GIT PATCH] Remove devfs from 2.6.13

[Greg KH <gregkh@suse.de>]

On Sat, Sep 10, 2005 at 04:03:12PM -0700, Mike Bell wrote:
> On Sat, Sep 10, 2005 at 02:52:54PM -0700, Greg KH wrote:
> > I didn't say it was a "nice" solution, fully LSB compliant and all.  All
> > it is is a solution that can work for some people, if they just want a
> > small, in-kernel devfs-like solution.
> 
> It's not a solution if it doesn't /work/. If you think this works for
> anyone who likes devfs, you clearly still don't understand what said
> people like about devfs in the first place.

Said people who like devfs are lazy and don't like running userspace
programs.  They pretty much also are pretty restricted to embedded
systems.  That's all I have been able to determine so far.  Care to help
flush this profile out some?

> > And it works just fine for alsa and input devices for me, just no
> > subdirs :)
> 
> What version of alsa libraries are you using that can deal with the
> device nodes in the root of /dev? I'm grepping the latest source code
> right now and I don't see it. Or is this yet another one of those facts
> you just made up? In what sense can alsa be said to work if zero alsa
> programs work?

My applogies, I used the OSS compatible module for ALSA when I tested
this out.  Hey, might as well use 1990's style interfaces, for 1990's
style kernel features... :)

> > Anyway, I'm not offering it up for inclusion in the kernel tree at
> > all, but for a proof-of-concept for those who were insisting that it
> > was impossible to keep a devfs-like patchset out of the main kernel
> > tree easily.
> 
> You can use ndevfs, if you don't care about your device nodes working.
> However that kind of defeats the purpose. To have a /working/ devfs-like
> solution you need the names, and currently the only way to get those is
> the devfs hooks.

Hm, ok, ALSA will not work.  Can you point to anything else?  Who cares
about sound on embedded systems anyway...

> Nobody is obligating you to provide a working ndevfs, but don't claim
> it's a solution when it's not. A devfs-like solution whose device nodes
> have random names which break programs is copying the form of devfs
> (exporting nodes from kernel space) and ignoring the point of devfs.

I'm claiming that the people who insisted that keeping the devfs
patchset outside of the mainline kernel was impossible.  I show how to
do this with 3 calls to "add a node" and three calls to "remove a node",
in a total of only 2 different kernel files.  Such a patch is _easily_
maintainable for pretty much forever outside the kernel tree.  Distros
maintain patches _way_ more complex and rough than that all the time.

That is my main point about ndevfs.

thanks,

greg k-h