Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Mike Bell]

On Wed, Jun 22, 2005 at 11:48:47PM -0700, Greg KH wrote:
> No, plan for it.  Speak up.  Complain sometime a while ago instead of
> right when it happens.

Did so. Raised the same points I'm doing now. Said at the time I was
going to wait and see if udev evolved to meet my needs before devfs got
removed. That time has arrived, and it hasn't, hence this. Seems
sensible to me.

> When did I ever say this?  I have only ever said it was an option that
> people who want dynamic /dev and persistant naming can use.  There are
> other projects out there becides udev that do much the same thing in
> userspace, udev isn't the only one.

But they all use fundamentally the same interface as udev and thus none
of them is any different with regard to my problems with udev, no?

> > Even before the official removal date was announced, vocal udev
> > proponents actively discouraged out-of-tree projects from accepting
> > devfs fixes.
> I was not aware of this.

Nonetheless true, and an example of the kind of problems maintaining
it out of tree would only make worse. And are you yourself not an
advocate of not caring if one breaks anything out of tree?

> He did, as did others.  However no one actually did the work, and were
> persistant, which is what really matters in this community.

The process for getting code into mainline involves getting someone "in
the loop" to adopt your patch. If no one looks like they are going to do
that, your effort is wasted. What is one supposed to do?

> namespace policy does?  Yes, the LANNANA one.  A non-LSB standard should
> not.

> See the above point about LSB.

See my point about how I don't care about devfs's specific namescheme,
how driver authors should pick the names for their devices, and how if
you mean "these particular names don't belong in the kernel" you should
say as much, not "policy in kernel".

> But for persistant device naming, you need to do this in userspace, the
> kernel can not do it (and before the old ptx developers pipe up, yes,
> you all did do this within your kernel years ago, but your performance
> sucked and I'm not putting a whole database into our kernel...)

You can't reasonably have "this USB fob will always have this name but
another of the same make will have a different name" without userspace
help, nor should you, but you can have "all v4l devices show up in this
form" and the like. Which, for the vast majority of cases, is enough.

> udev allows different /dev naming schemes, even a devfs-compatible one
> so you don't have to change any other programs if you want so.  devfs
> was unable to provide different ones.
> 
> > As long as I can have my USB serial wireless modem named
> > "/dev/usb-serial-wireless-modem" via a symlink, why should I care that
> > the canonical name is something about USBttyS?
> 
> dot-files will die that way :(

Not if they follow the symlink as they should.

> Becides them, no, you shouldn't, in fact, some distros use udev that way
> today.

So basically you've stated that this way of doing things is fine? And
since there's nothing to stop this way of doing things from happening
with devfs and a small, optional userspace helper to come up with
meaningful symlinked names based on logic that cannot reasonably be put
in the kernel....

> What distro shipps support for devfs and a 2.6 kernel?  I am not aware
> of one (Gentoo doesn't count, they don't "ship" anything :)  Honestly, I
> don't know of any.  I do know of a lot of them that ship udev.

Debian? Their installer even relies on devfs instead of udev. And
following up absolute statements like "no distro uses it" with things
like "gentoo doesn't count" is why I never trust the things you say.
"udev is smaller than devfs", if you discount sysfs. Or earlier "udev
does everything devfs does" comments which were actually "can
theoretically do these things, but currently isn't implemented, and it
only works with a handful of devices"

> But it was unmaintained clutter and mess.

Which people have attempted to maintain. Presumably, had it not been
marked OBSOLETE and thus useless to bother maintaining in the eyes of
most, said patches would have gone in just like any other cleanup, and
just like devfs cleanups had been doing until that point.

> See Al Viro's comments about this, and then try to refute them.  It's
> not just me saying this at all.  In the end, no one has fixed them to
> prove him wrong so he might just be on to something...

If this is about the stupid race, I don't see why all of devfs should be
damned for a feature no one (to my knowledge) uses anyway and thus could
be easily ripped out without the objections of devfs-liking people. See
above comments about a single canonical name for devices.

> There is only 1 thing that I know of that devfs does that udev does not,
> auto-module-loading if you try to access a device node that isn't
> present.  See my previous posts as to why this is a unworkable scheme
> anyway for 99% of the kernel devices.  Yes, the other 1% can use this,
> like ppp and raw.  But the distros have already solved this issue, so
> it's kind of moot.

I mentioned earlier that my main problems with udev were the continued
reliance on a partially static /dev, the way /dev is no longer
representative of the kernel's state, the reliance on sysfs to get any
usable system (assuming you treat static /dev as an unacceptable option,
which it is increasingly becoming) and most especially the early
userspace stuff. But before I assume you're making it up again I do need
to check your claims that these things have been addressed.

> Is there anything else that devfs can do that udev can't?  I have a
> whole list of things that udev can do that devfs can not :)

But I'll wager none (well, not if you exclude
features-that-aren't-features in my mind like "not being devfs" and "not
having device names in the kernel) that I can't accomplish just fine on
a devfs using system, right? You said yourself that udev isn't intended
to be a dynamic dev, that's just a fringe benefit. So there's absolutely
nothing stopping me using hotplug and sysfs with devfs - as I do right
now - to gain the features of udev without losing devfs.

> > After being forced to do so by the sudden surprise deprication of devfs
> > and the ensuing publicity to udev.
> 
> I have not forced _any_ company to do so.  I have not even _asked_ any
> company to do so.  I have simply been amazed that so many companies
> siezed on udev and brought it up to maturity and shipped it.  That tells
> me that people really wanted it and see the advantages of it over devfs.

Mysteriously and coincidentally in a great burst around the time devfs
was marked obsolete and you repeatedly commented that people needed to
switch away from devfs or risk getting caught where I am now? :)

> I have not heard any such issues in the past 6 months.  Hence my
> supprise now (well, not really supprise, I knew someone would complain,
> pretty amazed that it's only been one person in public (and one person
> privatly) so far.)

Because when patches to fix it get ignored, what else can one do? Who
wants to pipe up with "I like devfs" only to be told "you're stupid, if
you think you like devfs you don't understand udev" and knowing that
even saying so you don't really stand a chance of saving it?

> Then use the devfs mode of udev.  The devfs author even sent me updates
> in order to get them to work properly for his machines...

The names aren't my concern, the early-boot behaviour, partially static
nature, and other such incompatibilities are.

> I have never, until now, forced anyone to use udev. 

Technically true given the definition of the word "forced". But will you
not concede that the whole "OBSOLETE" thing, especially at such an early
stage in udev's maturity, was a good deal more of a strong-arm tactic
than the kernel usually sees?

> And even now, I'm not forcing anyone (there are other solutions to a
> dynamic /dev becides udev).

Yeah, the name of the userspace app doesn't mean a lot to me, they're
all forced to rely on the same kernel<=>userspace communication
mechanism and basically all work the same. I never complained about the
way udev handles its job in userspace, only about the removal of what
IMHO is a superior interface to kernelspace which offers things udev
alone cannot.

> I do feel, and it seems others agree, that udev is a far superior
> solution to the persistant device naming issue than devfs is

Wouldn't disagree with this. In fact, I'll come right out and say that
given the complete stagnation of devfs (which, I would argue, is not
entirely its own fault as you claim) and udev's rapid advances (based to
some degree I would argue on the attention it gained from things like
the marking of devfs obsolete) udev is the better solution today
(ignoring the migration headache and pretending both were completely new
systems introduced today, the features it offers that devfs doesn't are
worth much more than those devfs offers and udev doesn't, and it has a
much stronger community behind it).

But I also think that an even better solution could have been built
around the idea of a simple devfs that presented a single canonical
device file to userspace for each device and left the creation of
meaningful symlinks to an optional sysfs-using userspace helper. This
would have eliminated dependence on sysfs for the majority of systems I
know of, which rarely have custom rules giving more meaning to a device
than devfs currently presents, leaving me with all the features of devfs
I enjoy today and no migration headache, but a simple sysfs-using
userspace I could optionally apply to gain the features of udev. And
before you say something about "why didn't I then", I'd like to point
out that feature-wise I have that today, the only thing lacking is the
cleanups of devfs code, which really wasn't my primary concern and based
on the examples of others wouldn't have gotten in even if I had written
them.


So in closing, while I disagree with the whole way this has gone about,
in terms of things that can be done /now/ all I'm asking is that kernel
developers reevaluate the assumption that devfs is truly obsolete rather
than merely depricated, based on the fact that even after all this time
and energy udev is still not seen as a complete replacement by everyone.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/