Re: DEVFS is very good compared to UDEV

From: Ian Kent
Date: Sat Dec 27 2003 - 07:00:14 EST


On Tue, 23 Dec 2003, Jari Soderholm wrote:

>
> Booting kernel is faster compared to UDEV.

Mmm. Doesn't seem that way to me. What have I missed?

>
> UDEV otherwise is very complex for average user and it
> is definetly much slower , it has much greater chance
> for errors because very complicated scrips which seem
> to need many different gnu commandline utilities.

Didn't seem to difficult to me when I checked out both systems this last
few days. In fact I like'em both.

>
> It is quite funny that when DEVFS creates device files
> automagically and in the ram-memory, some people want
> to go backwards, and use shell scripts to
> create those files on hard disk, and then it is technically better solution.

Some how I don't think that's the reason for that statement.

>
> If one you look at the /sysfs-directory there are
> device filenames, (but not the actual devicefiles), so
> it does same thing that DEVFS, but actually much worce
> way, it created devicefilenames in the ram, but
> one cannot use them, because they are not devicefiles.

Looks to me like that was never the aim of sysfs. I haven't checked into
sysfs yet but I suspect it is quite different to devfs.

>
> Why could you develop it so that UDEV could create those
> actual device files there also, then most linux
> users would not need those horrible scipts anymore.
> All that is then needed link from /sysfs to /dev dir.

That would take away the ability to have a changeable device naming
scheme. One of the main reasons for having dynamic device name mapping
system is to map the names from a device detection system to specified
(possibly changing) naming scheme.

Please don't get me wrong. I like devfs very much and I see it has come a
long way since I last used it, but it needs work just to maintain its
current functionality within 2.6.

Ian


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