linux hotplug/hotplug-ng

linux hotplug/hotplug-ng

[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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: linux hotplug/hotplug-ng

[Alexander E. Patrakov]

Kasper Sandberg wrote:

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

>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).

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: linux hotplug/hotplug-ng

[Greg KH]

On Thu, Aug 11, 2005 at 09:59:27AM +0200, Kasper Sandberg wrote:
> 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 :)

> 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.)

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

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

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: linux hotplug/hotplug-ng

[Kasper Sandberg]

On Thu, 2005-08-11 at 11:20 -0700, Greg KH wrote:
> On Thu, Aug 11, 2005 at 09:59:27AM +0200, Kasper Sandberg wrote:
> > 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 :)
> 
> > 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...
nah. hotplug-base are..
> 
<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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: linux hotplug/hotplug-ng

[Kasper Sandberg]

On Thu, 2005-08-11 at 11:20 -0700, Greg KH wrote:
<snip>
> 
> 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?  
> 
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..

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: linux hotplug/hotplug-ng

[Kay Sievers]

On Sun, Aug 14, 2005 at 04:12:10PM +0200, Kasper Sandberg wrote:
> On Thu, 2005-08-11 at 11:20 -0700, Greg KH wrote:
> <snip>
> > 
> > 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?  
> > 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: linux hotplug/hotplug-ng

[Kasper Sandberg]

On Sun, 2005-08-14 at 21:33 +0200, Kay Sievers wrote:
<snip>
> 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.
that is fine too.. all i want is to get rid of those bash scripts.

> (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 seems nice :)
> 
> 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. :)


> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel