Re: udev and hotplug

[Kay Sievers <kay.sievers@vrfy.org>]

On Wed, 2006-10-11 at 14:39 +0530, Raj Kumar Yadav wrote:
>     I am using udev-100 on linux-2.6.14.
>     To make udev work, the kernel built options are following.
> 
>     Device Drivers  --->
>      Generic Driver Options  --->
>         <*> Hotplug firmware loading support
> 
>     File systems  --->
>      [*] Inotify file change notification support
> 
>     During the bootup, one time initialization of the /dev using "udevstart"
>     and afterwards running the "udevd" as daemon. The udev rules are working
>       as expected on every insertion/removal of devices.
> 
>     However, would like to clarify some minor doubts.
> 
>     1. Why do I need to enable "Hotplug firmware loading support" option, when
>         it seems that the "inotify" is passing all needed information to udevd.

Inotify sends you events if something in the filesystem changes, it has
absolutely nothing to do with a firmware-file loaded into a device. 

Udevd uses inotify to watch changing udev rules files and reloads its
config on demand.

>        "cat /proc/sys/kernel/hotplug" shows "/sbin/hotplug". But there is no
>          file as "/sbin/hotplug".

That's good not to have /sbin/hotplug. Even when there is no program to
fork anymore, you should disable the forking by the kernel, by setting
it to "".

>        According to the link hotplug is redundant now, but then why do I need to
>          enable the hotplug configuration in kernel 2.6.14.
>        http://vrfy.org/log/recent-state-of-udev.html

"hotplug" is the kernels ability to adapt to a changing device
environment, it's not the old userspace "hotplug" crap.

>     2. As it seems udev is providing all required functionality, Do one really
>        need to implement "hal" to exploit udev functionality.

It's functionality udev does not provide, like classification of
devices, device permission granting for "local" users, polling for media
changes. HAL is the foundation for all Desktop device handling. None of
its features will ever be implemented in udev, but if you don't miss
them, you probably don't need HAL.

>     3. Is it necessary to run "udevstart" to populate the /dev directory, should
>          it not be populated by the udevd internally. Please correct me, If I am
>        mixing two unrelated components.

Udevstart will be removed from a future udev version, it's not installed
by default. Kernel 2.6.15 has a way to re-request all events by
udevtrigger, which does not need udevstart. You just start the daemon,
run udevtrigger and all events are handled by the daemon, which will
populate /dev.

Kay


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel