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

From: David Brownell
Date: Wed Jun 22 2005 - 23:11:40 EST


Quoth Mike Bell:
>
> > Also, no disto uses devfs only (gentoo is close, but offers users udev
> > and a static /dev also.)
>
> It breaks a lot of my embedded setups which have read-only storage only
> and thus need /dev on devfs or tmpfs.

I'd agree that embedded setups are the ones that have been slowest to
switch over, for various reasons. One of them is that many LKML folk
ignore embedded systems issues; "just PC class or better". Another
has been that the basic hotplug scripts never worked well with "ash",
and who's going to want to ship "bash" and friends? :)

Those problems seem resolved with 2.6.12 and current modutils and udev.
Leaving basically an "upgrade your userspace" requirement.


> and thus need /dev on devfs or tmpfs. With early-userspace-udev-on-tmpfs
> being - in my experience - still unready.

Hmm, could you explain why you think udev-on-ramfs/tmpfs/... is still
unready? And what it's "unready" for? It can work fine without
needing to hack early userspace and initramfs, by the way. :)

I recently submitted patches to make buildroot support it. They're
mostly merged [1] but adding a simple patch fixes up the remaining
glitches. OpenEmbedded has supported it for a while too.

In short, I think udev-on-ramfs is simple enough to set up on 2.6.12
based embedded configs, and with "modprobe -q $MODALIAS" phasing in,
it seems to me [2] that hotplug-with-udev [3] can do most of what
folk have used devfs to achieve. I've quilted buildroot so that it
works that way by default for me; it's turnkey, with no problems.

Of course, 2.6.13 will be better with cardmgr finally gone. :)

- Dave

[1] http://bugs.busybox.net/view.php?id=290
[2] http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=111903617808816&w=2
[3] http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=111903647518255&w=2

-
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/