From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Wed, 11 Oct 2006 09:28:46 +0000 Subject: Re: udev and hotplug Message-Id: <1160558926.3539.13.camel@localhost> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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&kid0709&bid&3057&dat1642 _______________________________________________ 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