[ CC list trimmed to spare Linus and Andrew the mailbox clutter ]
On Sep 14, 2005, at 16:00:49, Mike Bell wrote:
On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
Said people who like devfs are lazy and don't like running
userspace programs.
What I don't like is when someone arbitrarily declares that their
half-finished project obsoletes a working one, and yet even a full
year later with a massive development community using the latest
kernel features (sometimes added specifically for that project) it
isn't a full
replacement for a project that has been - in your own words -
unmaintained for years and years.
What exactly does devfs do that udev doesn't, exactly? I haven't
been able to find anything on my wide variety of hardware, although I
will admit that there are some drivers that do not yet fully/
correctly use the new driver model.
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?
Probably because they're the people building linux systems from
scratch and caring about the size and speed of the result?
udev isn't that big or that slow, especially not the new netlink-
socket version, so unless you can provide a concrete example, I'm not
entirely sure what you're talking about.
My applogies, I used the OSS compatible module for ALSA when I
tested this out.
And while some input subsystem users force you to specify a device
node, this method is incompatible with hotplugging so the more
advanced ones rely on finding the input device nodes where they're
supposed to be, as they should.
What makes you think specifying nodes is incompatible with
hotplugging? I have my USB mouse and keyboard show up as /dev/
gyration_mouse and /dev/macally_keyboard, and I point my little input
event program at those. Admittedly, X kinda gets confused when I
unplug and those go away, but X doesn't support hotplugging anyways.
Hm, ok, ALSA will not work. Can you point to anything else?
See above. And of course ndevfs doesn't create the device nodes
that udev doesn't support (yes, even in 2.6.12 devfs still
supported more devices than udev on my test system).
So there are broken non-new-driver-model drivers. If you depend on
them (especially if you depend on them for your commercial product),
please feel free to fix them, because otherwise they won't be, and
they'll get more out of date with every kernel release until somebody
deletes them because they're unmaintained.
...before deciding there was no way to make it work without adding
sysfs attributes.
See above. Feel free to fix the driver if you need it.
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.
ndevfs doesn't work,
Yes it does. It works correctly for me.
and isn't even remotely compatible with devfs.
So? You need to change your /dev paths _now_. You've known that
those paths were kinda going away for a _long_ time, so it's not like
you haven't had time to fix your code that used them. And if you
need a kernel-generated /dev, then ndevfs will work (albeit with sane
paths, as opposed to the old devfs /dev/ide/host0/bus0/... crap).
Yes, ndevfs is easy to maintain out of the kernel tree. But since
ndevfs has absolutely nothing to do with devfs, that doesn't change
the fact that devfs can't be maintained out of the kernel tree.
devfs can't be maintained _within_ the kernel tree, let alone _out_
of it. Besides, it contained unfixable races, etc.
Anyway, if things continue the way they are with intentional devfs-
breakage having moved from out-of-tree drivers to in-tree drivers,
you'll get your wish soon enough when backhanded devfs removal
makes the in-tree version useless.
This sentence doesn't parse, perhaps you'd like to clarify? In any
case, devfs is going away because it's sufficiently racy and broken
and has been marked as DEPRECATED for a year. udev _has_ been
completely working for a while, even if not for the full year.
Cheers,
Kyle Moffett
--
There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
-- C.A.R. Hoare
-
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]
| |
 |