Re: devfs and udev

[Andreas Jellinghaus]

On Tue, 07 Oct 2003 21:51:27 +0000, Greg KH wrote:
> And remember, _I_ did not submit that patch to the kernel marking devfs
> obsolete.  Other kernel developers did.  And for good reasons, which
> have all been explained before.  Even if udev wasn't even written yet,
> it would have been done.

"Note that devfs has been obsoleted by udev,"

Most people expect after reading that sentence, that udev can do the
work devfs did for them. But udev is not ready to do that, even by
far. Thats why people complain.

Also all the documentation you mention doesn't help very much:
if someone wants to sit down, use devfs, even improve some parts
of the kernel with sysfs support, so sysfs will show all devices -
there is no documentation or example how to do that. The whole
kobject / sysfs / driver model code is by far not as easy to
understand as those devfs function calls are.

> Patches are always gladly accepted.

How can we patch udev, if sysfs doesn't seem to have the necessary
information. for example devfs has disc, floppy, cdrom. sysfs has only
/sys/block/hd*. Sorry, but I don't see how udev can create a result like
devfs did, without the necessary information in /sys. And the kernel
code isn't easy.

> People, come on, please read the existing documentation

show me that I'm wrong, and those questions I asked are documented,
and I will be happy and appologize. But I'm very sorry: even reading
your papers a hundred times doesn't show how drivers are supposed to
create custom entries for more devices. With devfs it's a five minute
look at a few drivers like floppy.c and printers.c and you get the idea.

Also the documentation is actualy confusing: why is a usb printer put
into class "usb" and not class printer? Why does udev decide the type
of device by matching /sys/block, why not export that data explicit?
Why not export default permissions, like devfs does?

With some answers, we might understand udev and sysfs better and might
be able to help. But asking for patches is not going to work, if basic
questions are left without answers.

Regards, Andreas

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