linux hotplug/hotplug-ng
hello.. i am sending this mail to this list on request of greg, so he can answer in public.
original mail:
the questions i have are about linux and hotplug, i dont fully understand how it works, and its relationship with udev.
i run gentoo with udev, and then i noticed that hotplug was not used as hotplug manager anymore, udevsend is. and then hotplug is not nessecary, so i unmerged hotplug and coldplug, because i believed that those bash scripts for modprobing modules of devices that you have would now be done via udevsend, however it does now...
then i read up, and it seems that i still need them, however, hotplug-ng should now be able to do this stuff for a few of the things hotplug bash scripts did, namely the pci "agent" as it was called in /etc/hotplug, which will autoload modules for pci stuff, which i guess also includes stuff like amd64-agp, which stopped being autoloaded after stopping to use coldplug...
i was wondering if you could explain to me how these things works, what i need for what, i would really like to get the autoloading part back with hotplug-ng.. if thats possible, so that i dont need those bash scripts anymore.. if all i need is hotplug-ng installed i can easily write a ebuild and stuff...
------
updates:
i already wrote an ebuild and installed hotplug-ng, however hotplugging isnt happening, when inserting stuff it doesent load modules.. is there a way to make hotplug-ng do what hotplug/coldplug does? also, if you should want my hotplug-ng ebuild its availiable here:
http://kaspersandberg.com/~redeeman/hotplug-ng-002.ebuild
basically what i have done is uninstall coldplug and hotplug, and installed hotplug-ng, i tried invoke hotplug-ng myself, but i couldnt get it to do anything...
Regards,
Kasper Sandberg
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Kasper Sandberg
then i read up, and it seems that i still need them, however, hotplug-ng should now be able to do this stuff for a few of the things hotplug bash scripts did, namely the pci "agent" as it was called in
/etc/hotplug, which will autoload modules for pci stuff, which i guess also includes stuff like amd64-agp, which stopped being autoloaded after stopping to use coldplug...
Yes, hotplug-ng was a replacement for *.agent, not *.rc scripts, and thus it cannot handle coldplug.
Quoted 8 lines
updates:
i already wrote an ebuild and installed hotplug-ng, however hotplugging isnt happening, when inserting stuff it doesent load modules.. is there a way to make hotplug-ng do what hotplug/coldplug does? also, if you should want my hotplug-ng ebuild its availiable here:
http://kaspersandberg.com/~redeeman/hotplug-ng-002.ebuild
hotplug-ng is dead. Forget that it exists. It was superseded by the "modalias" support in the recent kernels (>=2.6.12). Now there are several coldplug approaches proposed to replace the original hotplug scripts.
One is based on a tiny program that sits in initramfs and accumulates early hotplug events for passing them to udev. This completely elminates the need for separate coldplug scripts.
The second one is the proposal to modify the existing "udevstart" program so that it reconstructs the events nearly in the same way as the original *.rc scripts did.
Also it is necessary to mention the hotplug-light package from
http://www.bofh.it/~md/debian/ (to be used with either of the approaches).
Signature · 12 lines
Alexander E. Patrakov ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Kasper Sandberg
hello.. i am sending this mail to this list on request of greg, so he can answer in public.
original mail:
the questions i have are about linux and hotplug, i dont fully understand how it works, and its relationship with udev.
It's a mess, I agree :)
Quoted 5 lines
i run gentoo with udev, and then i noticed that hotplug was not used as hotplug manager anymore, udevsend is. and then hotplug is not nessecary, so i unmerged hotplug and coldplug, because i believed that those bash scripts for modprobing modules of devices that you have would now be done via udevsend, however it does now...
Ick, no, don't unmerge hotplug, it's still called by the Gentoo udev package. It's also still listed as a depandancy, so you did that against the package builder's wishes...
But sure, coldplug isn't needed if you don't want it, I really don't recommend anyone using that package on Gentoo due to a lot of bad side affects for some kinds of boxes. You are on your own if you use it (I recommend just using the /etc/modules.autoload.d/ stuff instead for modules you know you want to have loaded at boot time.)
Quoted 6 lines
then i read up, and it seems that i still need them, however, hotplug-ng should now be able to do this stuff for a few of the things hotplug bash scripts did, namely the pci "agent" as it was called in
/etc/hotplug, which will autoload modules for pci stuff, which i guess also includes stuff like amd64-agp, which stopped being autoloaded after stopping to use coldplug...
hotplug-ng is already obsolete, pretty much even before it had the chance to get anywhere.
Quoted 13 lines
i was wondering if you could explain to me how these things works, what i need for what, i would really like to get the autoloading part back with hotplug-ng.. if thats possible, so that i dont need those bash scripts anymore.. if all i need is hotplug-ng installed i can easily write a ebuild and stuff...
------
updates:
i already wrote an ebuild and installed hotplug-ng, however hotplugging isnt happening, when inserting stuff it doesent load modules.. is there a way to make hotplug-ng do what hotplug/coldplug does? also, if you should want my hotplug-ng ebuild its availiable here:
http://kaspersandberg.com/~redeeman/hotplug-ng-002.ebuild
Quoted 3 lines
basically what i have done is uninstall coldplug and hotplug, and installed hotplug-ng, i tried invoke hotplug-ng myself, but i couldnt get it to do anything...
Yes, as I said above, hotplug-ng is obsolete, you can do everything it did with just one udev rule :)
Anyway, here's how things are shaking themselves out:
udev will replace hotplug and hotplug-ng entirely. It almost does this already today in the Gentoo tree, but I need to spend a bit more time to tweak things properly to get it completly there. To do that we will just rely on the hotplug netlink messages coming out of the kernel and set /proc/sys/kernel/hotplug to NULL. udev will handle all of these messages, and shuttle them off to their proper places if needed. Combine udev with HAL and you pretty much have the full functionality of the old hotplug package, with lots of extra goodies added (speed, persistant naming, desktop notification, etc.)
An example of a distro that does all of this today is SuSE 10, you can take a look at it in the opensuse download. Kay is the one who got this all working properly, not me.
Does this help out any?
So, thanks for the hotplug-ng ebuild, but it's not going to be necessary anymore.
thanks,
greg k-h
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 16 lines · Greg KH
Quoted 6 lines · Kasper Sandberg
hello.. i am sending this mail to this list on request of greg, so he can answer in public.
original mail:
the questions i have are about linux and hotplug, i dont fully understand how it works, and its relationship with udev.It's a mess, I agree :)
Quoted 5 lines
i run gentoo with udev, and then i noticed that hotplug was not used as hotplug manager anymore, udevsend is. and then hotplug is not nessecary, so i unmerged hotplug and coldplug, because i believed that those bash scripts for modprobing modules of devices that you have would now be done via udevsend, however it does now...
Quoted 3 lines
Ick, no, don't unmerge hotplug, it's still called by the Gentoo udev package. It's also still listed as a depandancy, so you did that against the package builder's wishes...
nah. hotplug-base are..
Quoted 1 line
<snip>
i have heard that archlinux has some kind of alternative hotplug thing which should be quite good, perhaps i should look into that...
btw, if you repond, please cc me, im not on the list
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
On Thu, 2005-08-11 at 11:20 -0700, Greg KH wrote:
<snip>
Quoted 16 lines
Yes, as I said above, hotplug-ng is obsolete, you can do everything it did with just one udev rule :)
Anyway, here's how things are shaking themselves out:
udev will replace hotplug and hotplug-ng entirely. It almost does this already today in the Gentoo tree, but I need to spend a bit more time to tweak things properly to get it completly there. To do that we will just rely on the hotplug netlink messages coming out of the kernel and set
/proc/sys/kernel/hotplugto NULL. udev will handle all of these messages, and shuttle them off to their proper places if needed. Combine udev with HAL and you pretty much have the full functionality of the old hotplug package, with lots of extra goodies added (speed, persistant naming, desktop notification, etc.)
Quoted 6 lines
An example of a distro that does all of this today is SuSE 10, you can take a look at it in the opensuse download. Kay is the one who got this all working properly, not me.
Does this help out any?
yes, allthough i dont understand fully how udev can do this, except if it catches the hotplug messages from the kernel..
your idea seems very good, and i would like to help.. if you are interrested in me helping, you are welcome to msg me on irc(redeeman) or mail me..
Quoted 7 lines
So, thanks for the hotplug-ng ebuild, but it's not going to be necessary anymore.
thanks,
greg k-h
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 22 lines · Kasper Sandberg
On Thu, 2005-08-11 at 11:20 -0700, Greg KH wrote:
<snip>Quoted 20 lines
Yes, as I said above, hotplug-ng is obsolete, you can do everything it did with just one udev rule :)
Anyway, here's how things are shaking themselves out:
udev will replace hotplug and hotplug-ng entirely. It almost does this already today in the Gentoo tree, but I need to spend a bit more time to tweak things properly to get it completly there. To do that we will just rely on the hotplug netlink messages coming out of the kernel and set
/proc/sys/kernel/hotplugto NULL. udev will handle all of these messages, and shuttle them off to their proper places if needed. Combine udev with HAL and you pretty much have the full functionality of the old hotplug package, with lots of extra goodies added (speed, persistant naming, desktop notification, etc.)An example of a distro that does all of this today is SuSE 10, you can take a look at it in the opensuse download. Kay is the one who got this all working properly, not me.
Quoted 8 lines
Quoted 2 lines
Does this help out any?
yes, allthough i dont understand fully how udev can do this, except if it catches the hotplug messages from the kernel..
your idea seems very good, and i would like to help.. if you are interrested in me helping, you are welcome to msg me on irc(redeeman) or mail me..
udev is basically a replacement for the kernel forked /sbin/hotplug helper and the directory multiplexing in /etc/hotplug.d/.
The udev daemon receives the event from the kernel and creates an event handler that collects all nedded information about the specific device from sysfs and by calling small external tools, mostly from the extras/ folder of the udev tree. These tools have special knowledge about specific devices and provide udev with that information to match rules, create specific device names or run specific notification hooks.
The udev rules engine gives you fine grained control which tools are run and which notifications are hooked into an specific event for a specific device that the kernel sends an event for.
We already have had all the needed infrastructure to determine device names with udev, that it was a easy to take over the complete hotplug event handling. :)
udev does not replace the agent scripts or specific knowledge about a subsystem. But sure, most of the current hotplug agents and shell scripts have been or can be easily replaced by a bunch of rules for udev.
(A good example how much more efficient is the handling of a serial devices. With the old hotplug, you catched the device by hooking into the "tty" subsytem folder and your script got called for every tty device that was found. Then your script started to look at the event environment and just exited when it wasn't your "GPS device" that called you. :)
The bad side-effect is that on bootup your hook got called 600 times for all the /dev/tty* mess the kernel provides.
With udev you just create a rule that matches against a specific device property, like USB product/vendor, physical path, add a RUN key to that rule and you will get called only for that device!)
The second part of the big hotplug revamp is the MODALIAS string in sysfs and the hotplug environment. Using modutils directly to resolve a vendor/product id to a module name to load was the reason for hotplug-ng. hotplug-ng composed with the device id's from the individual buses a modalias string which is accepted from modprobe to resolve it to module name(s) to load.
After a while we played around with hotplug-ng, it was decided, that the kernel could compose that string directly and we can just pass that directly to modprobe. :)
That combined with the udev device match and fine grained tool execution based on device/event properties makes most of the old hotplug stuff obsolete and a lot of things very easy to switch over without any shell script involved.
A good starting point may to look at the copies of the distro rules in the udev tree and play a bit around with it. And if your system still uses stuff from /etc/dev.d/ or /etc/hotplug.d/ move that away and implement it as udev rules or small tools to get rid of it. :)
Good luck,
Kay
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
On Sun, 2005-08-14 at 21:33 +0200, Kay Sievers wrote:
<snip>
Quoted 17 lines
udev is basically a replacement for the kernel forked
/sbin/hotplughelper and the directory multiplexing in/etc/hotplug.d/.The udev daemon receives the event from the kernel and creates an event handler that collects all nedded information about the specific device from sysfs and by calling small external tools, mostly from the extras/ folder of the udev tree. These tools have special knowledge about specific devices and provide udev with that information to match rules, create specific device names or run specific notification hooks.
The udev rules engine gives you fine grained control which tools are run and which notifications are hooked into an specific event for a specific device that the kernel sends an event for.
We already have had all the needed infrastructure to determine device names with udev, that it was a easy to take over the complete hotplug event handling. :)
Quoted 3 lines
udev does not replace the agent scripts or specific knowledge about a subsystem. But sure, most of the current hotplug agents and shell scripts have been or can be easily replaced by a bunch of rules for udev.
that is fine too.. all i want is to get rid of those bash scripts.
Quoted 12 lines
(A good example how much more efficient is the handling of a serial devices. With the old hotplug, you catched the device by hooking into the "tty" subsytem folder and your script got called for every tty device that was found. Then your script started to look at the event environment and just exited when it wasn't your "GPS device" that called you. :)
The bad side-effect is that on bootup your hook got called 600 times for all the/dev/tty*mess the kernel provides.
With udev you just create a rule that matches against a specific device property, like USB product/vendor, physical path, add a RUN key to that rule and you will get called only for that device!)
Quoted 9 lines
The second part of the big hotplug revamp is the MODALIAS string in sysfs and the hotplug environment. Using modutils directly to resolve a vendor/product id to a module name to load was the reason for hotplug-ng. hotplug-ng composed with the device id's from the individual buses a modalias string which is accepted from modprobe to resolve it to module name(s) to load.
After a while we played around with hotplug-ng, it was decided, that the kernel could compose that string directly and we can just pass that directly to modprobe. :)
that seems nice :)
Quoted 10 lines
That combined with the udev device match and fine grained tool execution based on device/event properties makes most of the old hotplug stuff obsolete and a lot of things very easy to switch over without any shell script involved.
A good starting point may to look at the copies of the distro rules in the udev tree and play a bit around with it. And if your system still uses stuff from
/etc/dev.d/or/etc/hotplug.d/move that away and implement it as udev rules or small tools to get rid of it. :)
i will try install opensuse and look at their udev setup, and also try see all the udev configurations in the tarball.. and perhaps try do what i can figure out on my testsystem, to get my system working with hotplug, completely without those scripts. :)
Quoted 4 lines
Good luck,
Kay
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel