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.
> 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?
> 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.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |