[ANNOUNCE] hotplug-ng 001 release

[ANNOUNCE] hotplug-ng 001 release

[Greg KH]

I'd like to announce, yet-another-hotplug based userspace project:
linux-ng.  This collection of code replaces the existing linux-hotplug
package with very tiny, compiled executable programs, instead of the
existing bash scripts.

It currently provides the following:
	- a /sbin/hotplug multiplexer.  Works identical to the existing
	  bash /sbin/hotplug.
	- autoload programs for usb, scsi, and pci modules.  These
	  programs determine what module needs to be loaded when the
	  kernel emits a hotplug event for these types of devices.  This
	  works just like the existing linux-hotplug scripts, with a few
	  exceptions.

But why redo this all in .c code?  What's wrong with shell scripts?
Nothing is wrong with shell scripts, unless you don't want to have an
interpreter in your initramfs/initrd and you want to provide
/sbin/hotplug and autoload module functionality.  Or if you have a huge
box that spawns a zillion hotplug events all at once, and you need to be
able to handle all of that with the minimum amount of processing time
and memory.

So, how small are these programs?  Take a look:
   text    data     bss     dec     hex filename
   4669      32     124    4825    12d9 hotplug
   5077       8     348    5433    1539 module_pci
   4925       8     412    5345    14e1 module_scsi
   5349       8     348    5705    1649 module_usb

Those are all static binaries, linked with klibc (which is included in
the hotplug-ng package, just like udev.)

This compares to the following bash scripts:
-rwxr-xr-x  1 root root  4412 Feb 10 15:28 /sbin/hotplug
-rw-r--r--  1 root root   702 Sep 24 08:04 /etc/hotplug/blacklist
-rw-r--r--  1 root root  5293 Sep 24 08:04 /etc/hotplug/hotplug.functions
-rwxr-xr-x  1 root root  3739 Sep 24 08:04 /etc/hotplug/pci.agent
-rwxr-xr-x  1 root root  1459 Sep 24 08:04 /etc/hotplug/scsi.agent
-rwxr-xr-x  1 root root 13466 Sep 24 08:04 /etc/hotplug/usb.agent
-rw-r--r--  1 root root 39306 Sep 24 08:04 /etc/hotplug/usb.distmap
-rw-r--r--  1 root root  4364 Sep 24 08:04 /etc/hotplug/usb.handmap
-rw-r--r--  1 root root   189 Sep 24 08:04 /etc/hotplug/usb.usermap

All of which are loaded into memory for each hotplug event (for specific
hotplug events, only that bus type of file is loaded.)

But what about speed?  With a completely unscientific measurement on my
old, slow laptop, it takes about 2 seconds from the time I plug a usb
device into the machine, for the proper module to be loaded.  With the
hotplug-ng program, it takes less than a second.

And for those of you who might remember the old dietHotplug program that
also did the same thing in a tiny amount of space, this project
obsoletes that one.  dietHotplug had to be rebuilt for every kernel that
was used on the system, hotplug-ng uses the ability for modprobe to
determine the module that needs to be loaded based on the module
aliases[1].

The code can be found at:
	kernel.org/pub/linux/utils/kernel/hotplug/hotplug-ng-001.tar.gz
for those who wish to poke around in it.

I still have a few more programs to write to get it up to the same
functionality as the existing hotplug scripts (firmware, ieee1392, etc.)
but those will be done soon.  I'd like to get people's comments on the
idea, and welcome suggestions and even patches :)

hotplug-ng development is done in a BitKeeper repository located at:
	bk://linuxusb.bkbits.net/hotplug-ng

If anyone ever wants a tarball of the current bk tree, just email me.

thanks,

greg k-h

[1] modprobe as it currently works stops loading modules when it finds
an alias that matches.  This does not work for drivers that claim to
support "all devices" and then later on fail on devices that they really
don't support.  For that, all matching drivers need to be loaded for the
system to work properly.  The linux-hotplug scripts handle this
correctly, so if you rely on this functionality, please stick with that
package for now.  I'll be modifying modprobe to add this feature in the
near future.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.

Bah.  The name is hotplug-ng.  Sorry about that...

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Patrick McFarland]

Greg KH wrote:
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.  This collection of code replaces the existing linux-hotplug
> package with very tiny, compiled executable programs, instead of the
> existing bash scripts.
> 
> It currently provides the following:
> 	- a /sbin/hotplug multiplexer.  Works identical to the existing
> 	  bash /sbin/hotplug.
> 	- autoload programs for usb, scsi, and pci modules.  These
> 	  programs determine what module needs to be loaded when the
> 	  kernel emits a hotplug event for these types of devices.  This
> 	  works just like the existing linux-hotplug scripts, with a few
> 	  exceptions.
> 
> But why redo this all in .c code?  What's wrong with shell scripts?
> Nothing is wrong with shell scripts, unless you don't want to have an
> interpreter in your initramfs/initrd and you want to provide
> /sbin/hotplug and autoload module functionality.  Or if you have a huge
> box that spawns a zillion hotplug events all at once, and you need to be
> able to handle all of that with the minimum amount of processing time
> and memory.

Wow, thats pretty awesome. Just the other day I said, "Why is hotplug written 
in sh? Isn't that horribly inefficient way of handling something that needs to 
be done quickly using the least amount of resources possible?" It seems you 
were reading my mind.

Please, continue this project and encourage distros to switch to it (when it 
exceeds hotplug in functionality and stability). Ubuntu currently is trying to 
reduce boot time, and I bet something like this would factor in (even a few 
seconds helps).

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Thu, Feb 10, 2005 at 08:07:23PM -0500, Patrick McFarland wrote:
> 
> Please, continue this project and encourage distros to switch to it (when 
> it exceeds hotplug in functionality and stability). Ubuntu currently is 
> trying to reduce boot time, and I bet something like this would factor in 
> (even a few seconds helps).

Thanks for the kind words.

All distros are trying to reduce boot time.  I don't think that the
module autoload time has been fingered as taking any serious ammount of
boot time due to it happening in the background of everything else.  But
yes, this should help it out (as long as we aren't trading I/O time for
CPU time, like it can happen if you don't have a populated modules.alias
file...)

And yes, I've been in contact with the Ubuntu developer already about
using this code, instead of dietHotplug.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Kasper Sandberg]

hey greg

i remember for some months back, you posted something similar.. is this
a version thats ready for use? if it is! im gonna use it! :D

On Thu, 2005-02-10 at 16:52 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> > I'd like to announce, yet-another-hotplug based userspace project:
> > linux-ng.
> 
> Bah.  The name is hotplug-ng.  Sorry about that...
> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Bill Nottingham]

Greg KH (gregkh@suse.de) said: 
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.  This collection of code replaces the existing linux-hotplug
> package with very tiny, compiled executable programs, instead of the
> existing bash scripts.
> 
> It currently provides the following:
> 	- a /sbin/hotplug multiplexer.  Works identical to the existing
> 	  bash /sbin/hotplug.

How does this interact with current usage of udevsend as the hotplug
multiplexer?

Bill


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote:
> hey greg
> 
> i remember for some months back, you posted something similar.. is this
> a version thats ready for use? if it is! im gonna use it! :D

Yes, this is that version, cleaned up and given a proper build system,
and even tested on my machines here :)

thanks,

greg k-h



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Thu, 2005-02-10 at 22:18 -0500, Bill Nottingham wrote:
> Greg KH (gregkh@suse.de) said: 
> > I'd like to announce, yet-another-hotplug based userspace project:
> > linux-ng.  This collection of code replaces the existing linux-hotplug
> > package with very tiny, compiled executable programs, instead of the
> > existing bash scripts.
> > 
> > It currently provides the following:
> > 	- a /sbin/hotplug multiplexer.  Works identical to the existing
> > 	  bash /sbin/hotplug.
> 
> How does this interact with current usage of udevsend as the hotplug
> multiplexer?

First off, not everyone wants to use udev (I know, horrible thought...)
This provides those people a solution to a "I want a tiny /sbin/hotplug"
problem.

Also, udevstart working as /sbin/hotplug is great for keeping things in
order, which is important during normal operation.  But during the boot
sequence, the odds of getting out-of-order events, or even remove
events, is somewhat limited.  So, this /sbin/hotplug replacement can
work in an initrd/initramfs image when udevstart would be overkill.

And finally, even if you do use udevstart to manager /sbin/hotplug
events, you still need a module autoloader program.  This package
provides executables for that problem, if you don't want to (or you
can't) use the existing linux-hotplug scripts.  udev will never do the
module loading logic, so there's no duplication in this case.

Hope this helps.  I do realize the whole hotplug process is getting a
bit complicated.  I hope to write up some good documentation on what all
is involved to help clear up some of the confusion that the combination
of udev, udevsend, udevd, hal, /etc/hotplug.d/, /etc/dev.d/,
and /sbin/hotplug have caused lately.

thanks,

greg k-h



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Thu, Feb 10, 2005 at 10:46:57PM -0800, Greg KH wrote:
> On Thu, 2005-02-10 at 22:18 -0500, Bill Nottingham wrote:
> > How does this interact with current usage of udevsend as the hotplug
> > multiplexer?
> 
> [...]
> And finally, even if you do use udevstart to manager /sbin/hotplug
> events, you still need a module autoloader program.  This package
> provides executables for that problem, if you don't want to (or you
> can't) use the existing linux-hotplug scripts.  udev will never do the
> module loading logic

Why?

As a matter of fact I've been meaning to submit a patch to udev, adding
the functionaly to generate the fnmatch-able device name in the
module-init-utils' style, and propagate it to the hotplug callouts via
an environment variable, say DEVALIAS or MODNAME.  Then the only thing
left to do would be to teach modprobe to read this environment variable
when called without arguments, as well as $ACTION, and hook a symlink to
/sbin/modprobe in /etc/hotplug.d/default .

This would provide a smooth upgrade path and IMHO cause less confusion
with multiple hotplug multiplexers.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.

Bah.  The name is hotplug-ng.  Sorry about that...

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Olivier Galibert]

On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> 	- autoload programs for usb, scsi, and pci modules.  These
> 	  programs determine what module needs to be loaded when the
> 	  kernel emits a hotplug event for these types of devices.  This
> 	  works just like the existing linux-hotplug scripts, with a few
> 	  exceptions.

firmware?

  OG.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 11, 2005 at 11:10:44AM +0300, Roman Kagan wrote:
> As a matter of fact I've been meaning to submit a patch to udev, adding
> the functionaly to generate the fnmatch-able device name in the
> module-init-utils' style, and propagate it to the hotplug callouts via
> an environment variable, say DEVALIAS or MODNAME.

BTW this variable could be useful for other hotplug tasks, too.  E.g. if
a driver handles several device variants each needing a different
firmware, then the specific firmware can be put in a subdirectory with
a similar fnmatch-able name:

% cd /lib/firmware; find
./foo-firmware.bin                                           <- generic
./usb:v1234pABCDdl*dh*dc*dsc*dp*ic*isc*ip*
./usb:v1234pABCDdl*dh*dc*dsc*dp*ic*isc*ip*/foo-firmware.bin  <- specific

Then the hotplug firmware script would do something like

cd /lib/firmware
# specific
for d in *; do
	# in sh '=' means fnmatch
	if [[ $DEVALIAS = $d ]]; then
		if [[ -r "$d/$FIRMWARE" ]]; then
			...
			exit 0
		fi
	fi
done
# generic
if [[ -r "$FIRMWARE" ]]; then
	...
fi

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Kasper Sandberg]

On Thu, 2005-02-10 at 22:41 -0800, Greg KH wrote:
> On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote:
> > hey greg
> > 
> > i remember for some months back, you posted something similar.. is this
> > a version thats ready for use? if it is! im gonna use it! :D
> 
> Yes, this is that version, cleaned up and given a proper build system,
> and even tested on my machines here :)
ah cool. and in that case, you probably also have ebuilds for it, if you
do, please post them somewhere :)
> 
> thanks,
> 
> greg k-h
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Christian Bornträger]

On Friday 11 February 2005 07:46, Greg KH wrote:
> And finally, even if you do use udevstart to manager /sbin/hotplug
> events, you still need a module autoloader program.  This package
> provides executables for that problem, if you don't want to (or you
> can't) use the existing linux-hotplug scripts.  udev will never do the
> module loading logic, so there's no duplication in this case.

Greg,
the pci module autoloader is a real agent, which means it depends on having a 
hotplug event. Are you planning to support a scan for already present 
devices, like the pci.rc file in current hotplug solutions?

cheers

Christian


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 05:19:22PM +0100, Christian Borntr?ger wrote:
> On Friday 11 February 2005 07:46, Greg KH wrote:
> > And finally, even if you do use udevstart to manager /sbin/hotplug
> > events, you still need a module autoloader program.  This package
> > provides executables for that problem, if you don't want to (or you
> > can't) use the existing linux-hotplug scripts.  udev will never do the
> > module loading logic, so there's no duplication in this case.
> 
> Greg,
> the pci module autoloader is a real agent, which means it depends on having a 
> hotplug event. Are you planning to support a scan for already present 
> devices, like the pci.rc file in current hotplug solutions?

It's not only pci, but all types of busses need this kind of "coldplug"
functionality.  And yes, I have plans to provide that functionality in
this package too.

In fact, if anyone looking to contribute some well defined and easy to
test code... :)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 12:47:07PM +0100, Kasper Sandberg wrote:
> On Thu, 2005-02-10 at 22:41 -0800, Greg KH wrote:
> > On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote:
> > > hey greg
> > > 
> > > i remember for some months back, you posted something similar.. is this
> > > a version thats ready for use? if it is! im gonna use it! :D
> > 
> > Yes, this is that version, cleaned up and given a proper build system,
> > and even tested on my machines here :)
> ah cool. and in that case, you probably also have ebuilds for it, if you
> do, please post them somewhere :)

I don't have an ebuild for it yet, but it's on my list to get done.  And
when I do so, it will just show up in the normal gentoo tree.  The main
"issue" with this is I need to create a virtual for the hotplug service
so it doesn't conflict with the existing hotplug package.  Not a big
deal, just not as simple as adding a single ebuild to the tree.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 10:52:37AM +0100, Olivier Galibert wrote:
> On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote:
> > 	- autoload programs for usb, scsi, and pci modules.  These
> > 	  programs determine what module needs to be loaded when the
> > 	  kernel emits a hotplug event for these types of devices.  This
> > 	  works just like the existing linux-hotplug scripts, with a few
> > 	  exceptions.
> 
> firmware?

On the todo list :)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Christian Bornträger]

[-- Attachment #1: Type: text/plain, Size: 186 bytes --]

Greg KH wrote:
> In fact, if anyone looking to contribute some well defined and easy to
> test code... :)

Well, lets start with a small bugfix.
The agents segfault without a parameter.

[-- Attachment #2: segfault.patch --]
[-- Type: text/x-diff, Size: 506 bytes --]

diff -Nurp hotplug-ng-001/module_form.c new/module_form.c
--- hotplug-ng-001/module_form.c	2005-02-11 00:40:02.000000000 +0100
+++ new/module_form.c	2005-02-11 18:32:58.000000000 +0100
@@ -49,6 +49,10 @@ int main(int argc, char *argv[], char *e
 	int retval = 1;					\
 							\
 	logging_init("module_"#type);			\
+	if(argc == 1) {					\
+		dbg("this handler expects a parameter, aborting."); \
+		goto exit;				\
+	}						\
 							\
 	subsystem = argv[1];				\
 	if (strcmp(#type, subsystem) != 0) {		\

Re: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 06:41:23PM +0100, Christian Borntr?ger wrote:
> Greg KH wrote:
> > In fact, if anyone looking to contribute some well defined and easy to
> > test code... :)
> 
> Well, lets start with a small bugfix.
> The agents segfault without a parameter.

Nice catch, applied, thanks.

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Feb 11, Greg KH <gregkh@suse.de> wrote:

> It's not only pci, but all types of busses need this kind of "coldplug"
> functionality.  And yes, I have plans to provide that functionality in
> this package too.
Important feature request: some support for a /etc/hotplug/blacklist.d/
directory is needed before I can use it for the debian package.
I know that with the aliases method hotplug itself does not know the
actual module name, so maybe this should be discussed with Rusty and
added to modprobe.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Erik Andersen]

On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote:
> It's not only pci, but all types of busses need this kind of "coldplug"
> functionality.  And yes, I have plans to provide that functionality in
> this package too.
> 
> In fact, if anyone looking to contribute some well defined and easy to
> test code... :)

The pcimodules patch to pciutils does this sortof coldplug device
scanning for pci devices:
http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 12:01:54PM -0700, Erik Andersen wrote:
> On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote:
> > It's not only pci, but all types of busses need this kind of "coldplug"
> > functionality.  And yes, I have plans to provide that functionality in
> > this package too.
> > 
> > In fact, if anyone looking to contribute some well defined and easy to
> > test code... :)
> 
> The pcimodules patch to pciutils does this sortof coldplug device
> scanning for pci devices:
> http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch

Yes, but that uses the modules.pcimap files, which we want to get rid of
someday.  It also uses the /proc/pci interface instead of sysfs, so it
probably doesn't handle machines with pci domains very well...

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 07:47:20PM +0100, Marco d'Itri wrote:
> On Feb 11, Greg KH <gregkh@suse.de> wrote:
> 
> > It's not only pci, but all types of busses need this kind of "coldplug"
> > functionality.  And yes, I have plans to provide that functionality in
> > this package too.
> Important feature request: some support for a /etc/hotplug/blacklist.d/
> directory is needed before I can use it for the debian package.

Why?  Why not just not build the blacklisted modules?

> I know that with the aliases method hotplug itself does not know the
> actual module name, so maybe this should be discussed with Rusty and
> added to modprobe.

Yes, blacklisting should be a modprobe option, not a hotplug option.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 11:10:44AM +0300, Roman Kagan wrote:
> On Thu, Feb 10, 2005 at 10:46:57PM -0800, Greg KH wrote:
> > On Thu, 2005-02-10 at 22:18 -0500, Bill Nottingham wrote:
> > > How does this interact with current usage of udevsend as the hotplug
> > > multiplexer?
> > 
> > [...]
> > And finally, even if you do use udevstart to manager /sbin/hotplug
> > events, you still need a module autoloader program.  This package
> > provides executables for that problem, if you don't want to (or you
> > can't) use the existing linux-hotplug scripts.  udev will never do the
> > module loading logic
> 
> Why?

Do one thing, and do it well.

udev is for naming devices, not loading modules.
/sbin/hotplug is a tiny multiplexer.
the module autoload is a single program that only does just that.

> As a matter of fact I've been meaning to submit a patch to udev, adding
> the functionaly to generate the fnmatch-able device name in the
> module-init-utils' style, and propagate it to the hotplug callouts via
> an environment variable, say DEVALIAS or MODNAME.  Then the only thing
> left to do would be to teach modprobe to read this environment variable
> when called without arguments, as well as $ACTION, and hook a symlink to
> /sbin/modprobe in /etc/hotplug.d/default .
> 
> This would provide a smooth upgrade path and IMHO cause less confusion
> with multiple hotplug multiplexers.

Why, each type of autoload program needs to know how to handle the
different bus types.  So again, a single program doing a single thing
well.

I've threatened to add the module autoload logic to modprobe itself so
that it could work as a /sbin/hotplug catcher, but was throughly
rejected by the modprobe author :)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

On Feb 11, Greg KH <gregkh@suse.de> wrote:

> > Important feature request: some support for a /etc/hotplug/blacklist.d/
> > directory is needed before I can use it for the debian package.
> Why?  Why not just not build the blacklisted modules?
Because generic kernel packages are supposed to ship modules for the
different needs of different users.

> > I know that with the aliases method hotplug itself does not know the
> > actual module name, so maybe this should be discussed with Rusty and
> > added to modprobe.
> Yes, blacklisting should be a modprobe option, not a hotplug option.
It would have to enable blacklisting only when called by hotplug.
Can you describe the approved way to detect this situation?

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 08:40:39PM +0100, Marco d'Itri wrote:
> On Feb 11, Greg KH <gregkh@suse.de> wrote:
> 
> > > Important feature request: some support for a /etc/hotplug/blacklist.d/
> > > directory is needed before I can use it for the debian package.
> > Why?  Why not just not build the blacklisted modules?
> Because generic kernel packages are supposed to ship modules for the
> different needs of different users.

What packages modify the blacklist?  Or is that a userconfig type thing?

> > > I know that with the aliases method hotplug itself does not know the
> > > actual module name, so maybe this should be discussed with Rusty and
> > > added to modprobe.
> > Yes, blacklisting should be a modprobe option, not a hotplug option.
> It would have to enable blacklisting only when called by hotplug.

No, it would use blacklisting when called by aliases.  That would be
easier, right?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Harald Dunkel]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

Greg KH wrote:
> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.  This collection of code replaces the existing linux-hotplug
> package with very tiny, compiled executable programs, instead of the
> existing bash scripts.
>

cpio is running to setup a test partition.

But one question: This is yet another package with its
own private copy of klibc. Whats the reason behind this
non-modular approach?


Regards

Harri

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

On Feb 11, Greg KH <gregkh@suse.de> wrote:

> > Because generic kernel packages are supposed to ship modules for the
> > different needs of different users.
> What packages modify the blacklist?  Or is that a userconfig type thing?
Both. Some common examples are:
- the alsa-base package blacklisting all OSS modules, to disable OSS
- the hotplug package blacklisting all frame buffer modules,
  because they tend to fuck up X servers and are useless anyway
- the hotplug package blacklisting all watchdog modules, because they
  will reboot the computer if autoloaded when the user does not know
  about them
- users configuring some driver to not be autoloaded, e.g. because it's
  broken and locks up their system

> > > > I know that with the aliases method hotplug itself does not know the
> > > > actual module name, so maybe this should be discussed with Rusty and
> > > > added to modprobe.
> > > Yes, blacklisting should be a modprobe option, not a hotplug option.
> > It would have to enable blacklisting only when called by hotplug.
> No, it would use blacklisting when called by aliases.  That would be
> easier, right?
Looks like it is, I will think about it.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 11, 2005 at 07:47:20PM +0100, Marco d'Itri wrote:
> Important feature request: some support for a /etc/hotplug/blacklist.d/
> directory is needed before I can use it for the debian package.
> I know that with the aliases method hotplug itself does not know the
> actual module name, so maybe this should be discussed with Rusty and
> added to modprobe.

You can override the aliases you don't like in modprobe.conf (or a file
included therein, or a file specified with -C flag to modprobe).

If, however, modprobe is modified to try all matching aliases as per
Greg's suggestion, something like "unalias" will need to be added to
modprobe.conf syntax.

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

On Feb 11, Roman Kagan <rkagan@mail.ru> wrote:

> You can override the aliases you don't like in modprobe.conf (or a file
I cannot, because module-init-tools aliases are not recursive (blame
Rusty, he says this is a feature).

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Vojtech Pavlik]

On Thu, Feb 10, 2005 at 05:16:09PM -0800, Greg KH wrote:

> > Please, continue this project and encourage distros to switch to it (when 
> > it exceeds hotplug in functionality and stability). Ubuntu currently is 
> > trying to reduce boot time, and I bet something like this would factor in 
> > (even a few seconds helps).
> 
> Thanks for the kind words.
> 
> All distros are trying to reduce boot time.  I don't think that the
> module autoload time has been fingered as taking any serious ammount of
> boot time due to it happening in the background of everything else.

Hotplug scripts were identified as one of the major culprits of slow boot
when we did the analysis for SuSE 9.2. They took 40+ seconds from the
total boot time.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 11, 2005 at 09:20:34PM +0100, Marco d'Itri wrote:
> > You can override the aliases you don't like in modprobe.conf (or a file
> I cannot, because module-init-tools aliases are not recursive (blame
> Rusty, he says this is a feature).

I'm not sure I understand what you mean.  E.g. here's how I disable
sworks_agp which kills one of my machines if loaded:

% cat /etc/modprobe.conf
install	null	:
alias	pci:v00001166d*sv*sd*bc06sc00i00*	null

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 11, 2005 at 11:36:27AM -0800, Greg KH wrote:
> Do one thing, and do it well.
> 
> udev is for naming devices, not loading modules.

Well currently udev is doing a lot more: serializing, waiting for sysfs
dir to appear, etc.  Not that I disagree with your first statement,
though.

> Why, each type of autoload program needs to know how to handle the
> different bus types.  So again, a single program doing a single thing
> well.

udev already pokes enough in sysfs and has quite a lot of
subsystem-specific knowledge, so adding module name generation is not
too much of extra functionality.

OTOH I'm fine with them being separate programs, provided they get the
necessary info from sysfs so that they can be used for coldplugging too.
This will require adding wait_for_sysfs logic to them, though.

[ BTW could you please remind the motivation for doing wait_for_sysfs
instead of fixing the kernel to call out the hotplug usermode helper
only after the correspoding sysfs directory has completed initializing? ]

Thanks,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Feb 11, Roman Kagan <rkagan@mail.ru> wrote:

> On Fri, Feb 11, 2005 at 09:20:34PM +0100, Marco d'Itri wrote:
> > > You can override the aliases you don't like in modprobe.conf (or a file
> > I cannot, because module-init-tools aliases are not recursive (blame
> > Rusty, he says this is a feature).
> 
> I'm not sure I understand what you mean.  E.g. here's how I disable
> sworks_agp which kills one of my machines if loaded:
> 
> % cat /etc/modprobe.conf
> install	null	:
> alias	pci:v00001166d*sv*sd*bc06sc00i00*	null

This is not practical, drivers must be disabled by name because the
aliases will change with time.

What I meant is that this does not work:

# alias provided by the kernel
alias pci:foo*bar	foo_driver
# alias provided by the user
alias foo_driver	null

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 09:06:40PM +0100, Harald Dunkel wrote:
> Greg KH wrote:
> >I'd like to announce, yet-another-hotplug based userspace project:
> >linux-ng.  This collection of code replaces the existing linux-hotplug
> >package with very tiny, compiled executable programs, instead of the
> >existing bash scripts.
> >
> 
> cpio is running to setup a test partition.
> 
> But one question: This is yet another package with its
> own private copy of klibc. Whats the reason behind this
> non-modular approach?

Because we don't have an easy way yet to build against a copy of klibc
on a system?  For right now, it's the simplest way to ensure that it
works for everyone, once klibc moves into the kernel tree I can remove
it from udev and hotplug-ng.

Is it causing problems for you?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Kay Sievers]

On Fri, Feb 11, 2005 at 11:46:27PM +0300, Roman Kagan wrote:
> On Fri, Feb 11, 2005 at 11:36:27AM -0800, Greg KH wrote:
> > Do one thing, and do it well.
> > 
> > udev is for naming devices, not loading modules.
> 
> Well currently udev is doing a lot more: serializing, waiting for sysfs
> dir to appear, etc.  Not that I disagree with your first statement,
> though.

Well, we do what we need to do, to make device naming work. All this is
mainly a side effect of being able to name device in the order they depend
on each other.

> > Why, each type of autoload program needs to know how to handle the
> > different bus types.  So again, a single program doing a single thing
> > well.
> 
> udev already pokes enough in sysfs and has quite a lot of
> subsystem-specific knowledge, so adding module name generation is not
> too much of extra functionality.
> 
> OTOH I'm fine with them being separate programs, provided they get the
> necessary info from sysfs so that they can be used for coldplugging too.
> This will require adding wait_for_sysfs logic to them, though.

In the coldplugging case you don't need to wait for any sysfs file and
udevd will wait for you at event driven setups. So there is no need for any
software to wait for a file in sysfs.

> [ BTW could you please remind the motivation for doing wait_for_sysfs
> instead of fixing the kernel to call out the hotplug usermode helper
> only after the correspoding sysfs directory has completed initializing? ]

We can make the timing a bit better by moving the event
generation into the drivers, but this does not solve the problem, as you
can't really know what files are created at what time. We still need to do
something in userspace. But yes, it would be nice to make the kernel a
bit better here, cause the spinning and waiting for attribute costs a
lot of CPU what should be avoided. We already working on it, but it will
not replace the wait logic completely.

Thanks,
Kay


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 11:46:27PM +0300, Roman Kagan wrote:
> On Fri, Feb 11, 2005 at 11:36:27AM -0800, Greg KH wrote:
> > Do one thing, and do it well.
> > 
> > udev is for naming devices, not loading modules.
> 
> Well currently udev is doing a lot more: serializing, waiting for sysfs
> dir to appear, etc.  Not that I disagree with your first statement,
> though.
> 
> > Why, each type of autoload program needs to know how to handle the
> > different bus types.  So again, a single program doing a single thing
> > well.
> 
> udev already pokes enough in sysfs and has quite a lot of
> subsystem-specific knowledge, so adding module name generation is not
> too much of extra functionality.

If you look at the hotplug scripts, they really don't need to touch
sysfs at all.  (Note that the scsi one does, but I think we can fix the
scsi hotplug event to solve this issue...)

So module autoload has really nothing to do with sysfs.

Also, udev happens for the device _class_, not the device itself.
Modules bind to devices, device classes generate /dev nodes.  These
happen at two very different points in time (notibly the module events
need to happen before the device class ones are even able to be
generated.)  So udev has nothing to do with loading modules.

Also, for serialization, that's not needed for module loading as we
never unload modules automatically (that's impossible to do properly.)

> OTOH I'm fine with them being separate programs, provided they get the
> necessary info from sysfs so that they can be used for coldplugging too.
> This will require adding wait_for_sysfs logic to them, though.

coldplug can be a simple shell script, or eventually, something like
what udevstart is.  wait_for_sysfs stuff is not needed for that at all.

> [ BTW could you please remind the motivation for doing wait_for_sysfs
> instead of fixing the kernel to call out the hotplug usermode helper
> only after the correspoding sysfs directory has completed initializing? ]

How does the kernel know that the sysfs directory has completed
initializing?  :)

Note that Kay has proposed making the kobject registration a two step
process, generating the hotplug event later after the kobject has set up
sysfs "enough".  I'm reluctant to add that functionality as it make the
kernel more complex, and we've already solved the issue in userspace.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Kay Sievers]

On Fri, Feb 11, 2005 at 01:10:28PM -0800, Greg KH wrote:
> On Fri, Feb 11, 2005 at 11:46:27PM +0300, Roman Kagan wrote:
> > On Fri, Feb 11, 2005 at 11:36:27AM -0800, Greg KH wrote:
> > > Do one thing, and do it well.
> > > 
> > > udev is for naming devices, not loading modules.
> > 
> > Well currently udev is doing a lot more: serializing, waiting for sysfs
> > dir to appear, etc.  Not that I disagree with your first statement,
> > though.
> > 
> > > Why, each type of autoload program needs to know how to handle the
> > > different bus types.  So again, a single program doing a single thing
> > > well.
> > 
> > udev already pokes enough in sysfs and has quite a lot of
> > subsystem-specific knowledge, so adding module name generation is not
> > too much of extra functionality.
> 
> If you look at the hotplug scripts, they really don't need to touch
> sysfs at all.  (Note that the scsi one does, but I think we can fix the
> scsi hotplug event to solve this issue...)
> 
> So module autoload has really nothing to do with sysfs.
> 
> Also, udev happens for the device _class_, not the device itself.
> Modules bind to devices, device classes generate /dev nodes.  These
> happen at two very different points in time (notibly the module events
> need to happen before the device class ones are even able to be
> generated.)  So udev has nothing to do with loading modules.
> 
> Also, for serialization, that's not needed for module loading as we
> never unload modules automatically (that's impossible to do properly.)
> 
> > OTOH I'm fine with them being separate programs, provided they get the
> > necessary info from sysfs so that they can be used for coldplugging too.
> > This will require adding wait_for_sysfs logic to them, though.
> 
> coldplug can be a simple shell script, or eventually, something like
> what udevstart is.  wait_for_sysfs stuff is not needed for that at all.
> 
> > [ BTW could you please remind the motivation for doing wait_for_sysfs
> > instead of fixing the kernel to call out the hotplug usermode helper
> > only after the correspoding sysfs directory has completed initializing? ]
> 
> How does the kernel know that the sysfs directory has completed
> initializing?  :)
> 
> Note that Kay has proposed making the kobject registration a two step
> process, generating the hotplug event later after the kobject has set up
> sysfs "enough".  I'm reluctant to add that functionality as it make the
> kernel more complex, and we've already solved the issue in userspace.

Yeah, but the spinning costs a lot of CPU and should be avoided if it
that's so easy as the proposed change. The point is that for the drivers
nothing needs to change, but the class/block core can use it and it will make
the timing significant better and it safes us a lot of useless stat() cycles.

Kay


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 10:21:16PM +0100, Kay Sievers wrote:
> On Fri, Feb 11, 2005 at 01:10:28PM -0800, Greg KH wrote:
> > Note that Kay has proposed making the kobject registration a two step
> > process, generating the hotplug event later after the kobject has set up
> > sysfs "enough".  I'm reluctant to add that functionality as it make the
> > kernel more complex, and we've already solved the issue in userspace.
> 
> Yeah, but the spinning costs a lot of CPU and should be avoided if it
> that's so easy as the proposed change. The point is that for the drivers
> nothing needs to change, but the class/block core can use it and it will make
> the timing significant better and it safes us a lot of useless stat() cycles.

Hm, good point.  I still have your patch, and I'll consider it when I
get a few spare cycles here... :)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 09:56:14PM +0100, Marco d'Itri wrote:
> On Feb 11, Roman Kagan <rkagan@mail.ru> wrote:
> 
> > On Fri, Feb 11, 2005 at 09:20:34PM +0100, Marco d'Itri wrote:
> > > > You can override the aliases you don't like in modprobe.conf (or a file
> > > I cannot, because module-init-tools aliases are not recursive (blame
> > > Rusty, he says this is a feature).
> > 
> > I'm not sure I understand what you mean.  E.g. here's how I disable
> > sworks_agp which kills one of my machines if loaded:
> > 
> > % cat /etc/modprobe.conf
> > install	null	:
> > alias	pci:v00001166d*sv*sd*bc06sc00i00*	null
> 
> This is not practical, drivers must be disabled by name because the
> aliases will change with time.

Huh?  That's extremely pratical.  He's saying, "never load a module for
this specific type of pci device."  So if the module name changes for a
driver that happens to support that device, the line will still work
properly.

> What I meant is that this does not work:
> 
> # alias provided by the kernel
> alias pci:foo*bar	foo_driver
> # alias provided by the user
> alias foo_driver	null

Hm, time to make a "blacklist" file that is separate from the alias
stuff that handles this without needing recursion.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Erik van Konijnenburg]

On Fri, Feb 11, 2005 at 11:23:23AM -0800, Greg KH wrote:
> On Fri, Feb 11, 2005 at 12:01:54PM -0700, Erik Andersen wrote:
> > On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote:
> > > It's not only pci, but all types of busses need this kind of "coldplug"
> > > functionality.  And yes, I have plans to provide that functionality in
> > > this package too.
> > > 
> > > In fact, if anyone looking to contribute some well defined and easy to
> > > test code... :)
> > 
> > The pcimodules patch to pciutils does this sortof coldplug device
> > scanning for pci devices:
> > http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch
> 
> Yes, but that uses the modules.pcimap files, which we want to get rid of
> someday.  It also uses the /proc/pci interface instead of sysfs, so it
> probably doesn't handle machines with pci domains very well...

Could you give pointers to the "get rid of modules.pcimap" discussion?

Thanks.
Erik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 10:37:31PM +0100, Erik van Konijnenburg wrote:
> On Fri, Feb 11, 2005 at 11:23:23AM -0800, Greg KH wrote:
> > On Fri, Feb 11, 2005 at 12:01:54PM -0700, Erik Andersen wrote:
> > > On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote:
> > > > It's not only pci, but all types of busses need this kind of "coldplug"
> > > > functionality.  And yes, I have plans to provide that functionality in
> > > > this package too.
> > > > 
> > > > In fact, if anyone looking to contribute some well defined and easy to
> > > > test code... :)
> > > 
> > > The pcimodules patch to pciutils does this sortof coldplug device
> > > scanning for pci devices:
> > > http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch
> > 
> > Yes, but that uses the modules.pcimap files, which we want to get rid of
> > someday.  It also uses the /proc/pci interface instead of sysfs, so it
> > probably doesn't handle machines with pci domains very well...
> 
> Could you give pointers to the "get rid of modules.pcimap" discussion?

Search linux-kernel for it.  It's come up many times between me and
Rusty Russell.  He's basically waiting for the hotplug scripts (or
whatever) to be fixed up enough to not need them anymore.

Do you have some other need for them?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On Feb 11, Greg KH <gregkh@suse.de> wrote:

> Search linux-kernel for it.  It's come up many times between me and
> Rusty Russell.  He's basically waiting for the hotplug scripts (or
> whatever) to be fixed up enough to not need them anymore.
> 
> Do you have some other need for them?
Aliases for input devices are still missing.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 10:54:10PM +0100, Marco d'Itri wrote:
> On Feb 11, Greg KH <gregkh@suse.de> wrote:
> 
> > Search linux-kernel for it.  It's come up many times between me and
> > Rusty Russell.  He's basically waiting for the hotplug scripts (or
> > whatever) to be fixed up enough to not need them anymore.
> > 
> > Do you have some other need for them?
> Aliases for input devices are still missing.

See the recent patches on linux-kernel to try to fix this.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Bill Nottingham]

Greg KH (gregkh@suse.de) said: 
> > # alias provided by the kernel
> > alias pci:foo*bar	foo_driver
> > # alias provided by the user
> > alias foo_driver	null
> 
> Hm, time to make a "blacklist" file that is separate from the alias
> stuff that handles this without needing recursion.

/etc/hotplug/blacklist ? :)

Bill


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Erik van Konijnenburg]

On Fri, Feb 11, 2005 at 01:49:57PM -0800, Greg KH wrote:
> On Fri, Feb 11, 2005 at 10:37:31PM +0100, Erik van Konijnenburg wrote:
> > On Fri, Feb 11, 2005 at 11:23:23AM -0800, Greg KH wrote:
> > > On Fri, Feb 11, 2005 at 12:01:54PM -0700, Erik Andersen wrote:
> > > > On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote:
> > > > > It's not only pci, but all types of busses need this kind of "coldplug"
> > > > > functionality.  And yes, I have plans to provide that functionality in
> > > > > this package too.
> > > > > 
> > > > > In fact, if anyone looking to contribute some well defined and easy to
> > > > > test code... :)
> > > > 
> > > > The pcimodules patch to pciutils does this sortof coldplug device
> > > > scanning for pci devices:
> > > > http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch
> > > 
> > > Yes, but that uses the modules.pcimap files, which we want to get rid of
> > > someday.  It also uses the /proc/pci interface instead of sysfs, so it
> > > probably doesn't handle machines with pci domains very well...
> > 
> > Could you give pointers to the "get rid of modules.pcimap" discussion?
> 
> Search linux-kernel for it.  It's come up many times between me and
> Rusty Russell.  He's basically waiting for the hotplug scripts (or
> whatever) to be fixed up enough to not need them anymore.
> 
> Do you have some other need for them?

Yep, I'm working on a proof of concept to show how modules.pcimap
can be used to build a more reliable mkinitrd.  The interesting part about
modules.pcimap is that it can not only describe what's in the running
kernel, but also what's in the kernel about to be installed.

For an old version of the idea, see

	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug(4294

Regards,
Erik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 05:05:10PM -0500, Bill Nottingham wrote:
> Greg KH (gregkh@suse.de) said: 
> > > # alias provided by the kernel
> > > alias pci:foo*bar	foo_driver
> > > # alias provided by the user
> > > alias foo_driver	null
> > 
> > Hm, time to make a "blacklist" file that is separate from the alias
> > stuff that handles this without needing recursion.
> 
> /etc/hotplug/blacklist ? :)

Heh, no something modprobe specific.  /etc/modprobe.blacklist perhaps?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 11, 2005 at 09:56:14PM +0100, Marco d'Itri wrote:
> What I meant is that this does not work:
> 
> # alias provided by the kernel
> alias pci:foo*bar	foo_driver
> # alias provided by the user
> alias foo_driver	null

Even easier: replace the last line with

install foo_driver :

And you're done ;)

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Fri, Feb 11, 2005 at 11:06:57PM +0100, Erik van Konijnenburg wrote:
> For an old version of the idea, see
> 
> 	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug(4294

Very nice stuff.  Ok, that's a good reason not to get rid of these
files, although they can be generated on the fly from the modules
themselves (like depmod does it.)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

On Feb 11, Roman Kagan <rkagan@mail.ru> wrote:

> Even easier: replace the last line with
> 
> install foo_driver :
> 
> And you're done ;)
No, because other install lines may be present for the driver.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

On Feb 11, Greg KH <gregkh@suse.de> wrote:

> > /etc/hotplug/blacklist ? :)
> Heh, no something modprobe specific.  /etc/modprobe.blacklist perhaps?
It should be compatible with the current /etc/hotplug/blacklist
format *and* it should be a directory because it's the only sane way to
handle multiple packages updating it.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 11, 2005 at 11:06:57PM +0100, Erik van Konijnenburg wrote:
> For an old version of the idea, see
> 
> 	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug(4294

It looks like the same thing can be achieved by adding a flag to
modprobe to print the list of modules it would load, in the style of
modprobe -vn, but with no regard to whether any of them are already
loaded (should be a few lines of code).  Then just run coldplug with
such a flag passed to modprobe.

Or am I missing the point?

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 11, 2005 at 11:16:56PM +0100, Marco d'Itri wrote:
> On Feb 11, Roman Kagan <rkagan@mail.ru> wrote:
> 
> > Even easier: replace the last line with
> > 
> > install foo_driver :
> > 
> > And you're done ;)
> No, because other install lines may be present for the driver.

And the last one wins.  Isn't it what you wanted to achieve in your
example?

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Erik van Konijnenburg]

On Sat, Feb 12, 2005 at 01:45:19AM +0300, Roman Kagan wrote:
> On Fri, Feb 11, 2005 at 11:06:57PM +0100, Erik van Konijnenburg wrote:
> > For an old version of the idea, see
> > 
> > 	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug(4294
> 
> It looks like the same thing can be achieved by adding a flag to
> modprobe to print the list of modules it would load, in the style of
> modprobe -vn, but with no regard to whether any of them are already
> loaded (should be a few lines of code).  Then just run coldplug with
> such a flag passed to modprobe.
> 
> Or am I missing the point?

That's correct, but not the whole story.

Modprobe handles dependencies: in order to load module ata_piix,
you need libata.  That's a necessary part of the solution.
Coldplug walks sysfs and finds interesting stuff to feed to
the modules.pcimap parser and modprobe.  Also necessary.

What's extra is that mkinitrd needs to do this not for
the running kernel but for the next kernel, that it needs to
do so only for the modules needed to get the root operational,
and that it needs to coordinate that with support for non
hotplug devices like LVM and mdadm.

Regards,
Erik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

On Feb 11, Roman Kagan <rkagan@mail.ru> wrote:

> > No, because other install lines may be present for the driver.
> And the last one wins.  Isn't it what you wanted to achieve in your
> example?
I cannot control their order.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Sat, Feb 12, 2005 at 12:17:45AM +0100, Marco d'Itri wrote:
> On Feb 11, Roman Kagan <rkagan@mail.ru> wrote:
> 
> > > No, because other install lines may be present for the driver.
> > And the last one wins.  Isn't it what you wanted to achieve in your
> > example?
> I cannot control their order.

Nor could you with your aliasing example.

Besides, if you make sure your modprobe.blacklist is included at the end
of your modprobe.conf, you can guarantee the blacklisting wins.

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Feb 12, Roman Kagan <rkagan@mail.ru> wrote:

> On Sat, Feb 12, 2005 at 12:17:45AM +0100, Marco d'Itri wrote:
> > On Feb 11, Roman Kagan <rkagan@mail.ru> wrote:
> > 
> > > > No, because other install lines may be present for the driver.
> > > And the last one wins.  Isn't it what you wanted to achieve in your
> > > example?
> > I cannot control their order.
> 
> Nor could you with your aliasing example.
It's reasonable to expect that drivers modules are not aliased to
something else.

> Besides, if you make sure your modprobe.blacklist is included at the end
> of your modprobe.conf, you can guarantee the blacklisting wins.
I have no modprobe.conf, debian (and I understand SuSE too) uses
/etc/modprobe.d/.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Kasper Sandberg]

On Fri, 2005-02-11 at 09:06 -0800, Greg KH wrote:
> On Fri, Feb 11, 2005 at 12:47:07PM +0100, Kasper Sandberg wrote:
> > On Thu, 2005-02-10 at 22:41 -0800, Greg KH wrote:
> > > On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote:
> > > > hey greg
> > > > 
> > > > i remember for some months back, you posted something similar.. is this
> > > > a version thats ready for use? if it is! im gonna use it! :D
> > > 
> > > Yes, this is that version, cleaned up and given a proper build system,
> > > and even tested on my machines here :)
> > ah cool. and in that case, you probably also have ebuilds for it, if you
> > do, please post them somewhere :)
> 
> I don't have an ebuild for it yet, but it's on my list to get done.  And
> when I do so, it will just show up in the normal gentoo tree.  The main
> "issue" with this is I need to create a virtual for the hotplug service
> so it doesn't conflict with the existing hotplug package.  Not a big
> deal, just not as simple as adding a single ebuild to the tree.
just make it provide virtual/hotplug, then do a fgrep -r
"hotplug" /usr/portage/ and then replace with virtual/hotplug ;)
> 
> thanks,
> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Sat, Feb 12, 2005 at 12:35:10AM +0100, Marco d'Itri wrote:
> On Feb 12, Roman Kagan <rkagan@mail.ru> wrote:
> > Besides, if you make sure your modprobe.blacklist is included at the end
> > of your modprobe.conf, you can guarantee the blacklisting wins.
> I have no modprobe.conf, debian (and I understand SuSE too) uses
> /etc/modprobe.d/.

Then do use modprobe.conf, reading as

include /etc/modprobe.d
include /etc/modprobe-blacklist.d

Well, there are many possible scenarios, what I'm trying to say is that
the current modprobe.conf syntax is sufficient for blacklisting.

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Feb 12, Roman Kagan <rkagan@mail.ru> wrote:

> Then do use modprobe.conf, reading as
> 
> include /etc/modprobe.d
Having both files would be confusing.

> Well, there are many possible scenarios, what I'm trying to say is that
> the current modprobe.conf syntax is sufficient for blacklisting.
It's still not enough, because by using install:
- blacklisted modules would never be loaded, not only when requested by
  hotplug
- the syntax would not be backward compatible

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 11, 2005 at 01:10:28PM -0800, Greg KH wrote:
> If you look at the hotplug scripts, they really don't need to touch
> sysfs at all.  (Note that the scsi one does, but I think we can fix the
> scsi hotplug event to solve this issue...)
> 
> So module autoload has really nothing to do with sysfs.

Just to make sure I understand what you mean: is the idea that hotplug
scripts get the device IDs through the environment variables only, and
the coldplug's responsibility is to fetch the info from sysfs and make
up the same set of environment variables to pass to hotplug?

Then why not just make the kernel (and coldplug) create an additional
environment variable with the fnmatch-able module name ready to use with
modprobe?  Given that kernel (and coldplug) have all the IDs in the nice
integer form it would be a matter of a single add_hotplug_env_var() (or
sprintf()) call per each device type, and would be even tinier that the
hotplug-ng :)

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Ingo Oeser]

Hi,

Greg KH write:
> Very nice stuff.  Ok, that's a good reason not to get rid of these
> files, although they can be generated on the fly from the modules
> themselves (like depmod does it.)

Time to resurrect modinfo? ;-)
Didn't we plan to get rid of that, too?

If we like to use information from modules, there should be a scriptable 
tool to extract this kind of information, otherwise it will be a bitch to 
maintain those tools.


Regards

Ingo Oeser



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Harald Dunkel]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

Greg KH wrote:
>
> Because we don't have an easy way yet to build against a copy of klibc
> on a system?  For right now, it's the simplest way to ensure that it
> works for everyone, once klibc moves into the kernel tree I can remove
> it from udev and hotplug-ng.
>

If it is not possible to use klibc together with a non-Linux
system (e.g. FreeBSD or Mach), then I would suggest to make
klibc an optional kernel patch and drop it from udev and
hotplug.

> Is it causing problems for you?
>

Some months ago I had contributed a patch to add an install
target to the klibc Makefiles. I just wonder why it has been
ignored.


Regards

Harri

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Pozsár Balázs]

On Sat, Feb 12, 2005 at 01:17:50AM +0100, Marco d'Itri wrote:
> On Feb 12, Roman Kagan <rkagan@mail.ru> wrote:
> 
> > Then do use modprobe.conf, reading as
> > 
> > include /etc/modprobe.d
> Having both files would be confusing.
> 
> > Well, there are many possible scenarios, what I'm trying to say is that
> > the current modprobe.conf syntax is sufficient for blacklisting.
> It's still not enough, because by using install:
> - blacklisted modules would never be loaded, not only when requested by
>   hotplug

Exactly that's what I wanted to say: blacklisting should be done in 
hotplug _not_ modprobe: what we want, is preventing some modules to be 
loaded by hotplug, but we do want these to be loadable via modprobe.


-- 
pozsy


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Sat, Feb 12, 2005 at 03:34:58AM +0300, Roman Kagan wrote:
> Then why not just make the kernel (and coldplug) create an additional
> environment variable with the fnmatch-able module name ready to use with
> modprobe?  Given that kernel (and coldplug) have all the IDs in the nice
> integer form it would be a matter of a single add_hotplug_env_var() (or
> sprintf()) call per each device type, and would be even tinier that the
> hotplug-ng :)

To illustrate this with an example, here's what could be done in place
of hotplug-ng-001/module_usb.c:

--- linux-2.6.10/drivers/usb/core/usb.c.orig	2004-12-25 00:34:46.000000000 +0300
+++ linux-2.6.10/drivers/usb/core/usb.c	2005-02-12 14:43:53.514389160 +0300
@@ -654,7 +654,34 @@
 					alt->desc.bInterfaceSubClass,
 					alt->desc.bInterfaceProtocol))
 			return -ENOMEM;
+
+		if (add_hotplug_env_var(envp, num_envp, &i,
+					buffer, buffer_size, &length,
+					"MODNAME=usb:v%04Xp%04Xdl%04Xdh%04Xdc%02Xdsc%02Xdp%02Xic%02Xisc%02Xip%02X",
+					usb_dev->descriptor.idVendor,
+					usb_dev->descriptor.idProduct,
+					usb_dev->descriptor.bcdDevice,
+					usb_dev->descriptor.bcdDevice,
+					usb_dev->descriptor.bDeviceClass,
+					usb_dev->descriptor.bDeviceSubClass,
+					usb_dev->descriptor.bDeviceProtocol,
+					alt->desc.bInterfaceClass,
+					alt->desc.bInterfaceSubClass,
+					alt->desc.bInterfaceProtocol))
+			return -ENOMEM;
 	}
+	else
+		if (add_hotplug_env_var(envp, num_envp, &i,
+					buffer, buffer_size, &length,
+					"MODNAME=usb:v%04Xp%04Xdl%04Xdh%04Xdc%02Xdsc%02Xdp%02Xic*isc*ip*",
+					usb_dev->descriptor.idVendor,
+					usb_dev->descriptor.idProduct,
+					usb_dev->descriptor.bcdDevice,
+					usb_dev->descriptor.bcdDevice,
+					usb_dev->descriptor.bDeviceClass,
+					usb_dev->descriptor.bDeviceSubClass,
+					usb_dev->descriptor.bDeviceProtocol))
+			return -ENOMEM;
 
 	envp[i] = NULL;
 

Then only a generic $MODNAME (and $ACTION) handler would need to be
present in hotplug (and could rather be added to modprobe).

Given that module alias generation is already done in the kernel build
process, and aliases are included in the modules, generating such an
environment variable looks like a natural thing to do in-kernel too.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Alexander E. Patrakov]

Greg KH wrote:

> I'd like to announce, yet-another-hotplug based userspace project:
> linux-ng.  This collection of code replaces the existing linux-hotplug
> package with very tiny, compiled executable programs, instead of the
> existing bash scripts.

The ability to set up userspace handlers for certain devices via *.usermap
files (see SANE and gphoto2 for basic "chown and chmod a file
in /proc/bus/usb" examples) was lost. Is this functionality planned to be
restored in hotplug-ng? Or is it the responsibility of SANE and gphoto2
maintainers to adapt to this change e.g. by providing additional files
for /etc/hotplug.d/usb instead?

-- 
Alexander E. Patrakov


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Lee Revell]

On Thu, 2005-02-10 at 17:16 -0800, Greg KH wrote:
> All distros are trying to reduce boot time.

They certainly aren't all trying very hard.  Debian and Fedora (last
time I checked) do not even run the init scripts in parallel.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Paolo Ciarrocchi]

On Sun, 13 Feb 2005 23:06:51 -0500, Lee Revell <rlrevell@joe-job.com> wrote:
> On Thu, 2005-02-10 at 17:16 -0800, Greg KH wrote:
> > All distros are trying to reduce boot time.
> 
> They certainly aren't all trying very hard.  Debian and Fedora (last
> time I checked) do not even run the init scripts in parallel.

Is there any distro that is running the init scripts in parallel ?
-- 
Paolo <paolo dot ciarrocchi at gmail dot com>
msn: paolo407@hotmail.com
hello: ciarrop


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Paolo Ciarrocchi schrieb:
> On Sun, 13 Feb 2005 23:06:51 -0500, Lee Revell <rlrevell@joe-job.com> wrote:
>
>>On Thu, 2005-02-10 at 17:16 -0800, Greg KH wrote:
>>
>>>All distros are trying to reduce boot time.
>>
>>They certainly aren't all trying very hard.  Debian and Fedora (last
>>time I checked) do not even run the init scripts in parallel.
>
>
> Is there any distro that is running the init scripts in parallel ?

Gentoo.

--
Prakash Punnoor

formerly known as Prakash K. Cheemplavam

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Sat, Feb 12, 2005 at 09:30:54AM +0100, Harald Dunkel wrote:
> Greg KH wrote:
> >
> >Because we don't have an easy way yet to build against a copy of klibc
> >on a system?  For right now, it's the simplest way to ensure that it
> >works for everyone, once klibc moves into the kernel tree I can remove
> >it from udev and hotplug-ng.
> >
> 
> If it is not possible to use klibc together with a non-Linux
> system (e.g. FreeBSD or Mach), then I would suggest to make
> klibc an optional kernel patch and drop it from udev and
> hotplug.

But it is not possible to use udev or hotplug-ng on a non-Linux system,
right?

As far as "optional kernel patch"?  What do you mean?  People are
working on adding klibc to the main kernel tree, nothing optional about
that.

> >Is it causing problems for you?
> >
> 
> Some months ago I had contributed a patch to add an install
> target to the klibc Makefiles. I just wonder why it has been
> ignored.

Don't know, I'm not in charge of klibc development.  Why not ask on the
klibc mailing list?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Sat, Feb 12, 2005 at 03:34:58AM +0300, Roman Kagan wrote:
> On Fri, Feb 11, 2005 at 01:10:28PM -0800, Greg KH wrote:
> > If you look at the hotplug scripts, they really don't need to touch
> > sysfs at all.  (Note that the scsi one does, but I think we can fix the
> > scsi hotplug event to solve this issue...)
> > 
> > So module autoload has really nothing to do with sysfs.
> 
> Just to make sure I understand what you mean: is the idea that hotplug
> scripts get the device IDs through the environment variables only, and
> the coldplug's responsibility is to fetch the info from sysfs and make
> up the same set of environment variables to pass to hotplug?
> 
> Then why not just make the kernel (and coldplug) create an additional
> environment variable with the fnmatch-able module name ready to use with
> modprobe?  Given that kernel (and coldplug) have all the IDs in the nice
> integer form it would be a matter of a single add_hotplug_env_var() (or
> sprintf()) call per each device type, and would be even tinier that the
> hotplug-ng :)

You know, it's moments like this that I really think the open source
development model is the best.  People are able to look into a project
and point out how stupid the original designers/authors are at any
moment in time :)

You are completly correct, I love your kernel patch.  With it, and a few
minor changes to modprobe, we don't need _any_ of the module_* programs
in the hotplug-ng package I just released.  That is wonderful, thank you
so much for showing me that I was just working in circles.

I'll go work on this in the next few days (getting over being sick and
trying to catch up on email right now...)

Thanks again, I really appreciate it.

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Sat, Feb 12, 2005 at 01:48:49AM +0100, Ingo Oeser wrote:
> Hi,
> 
> Greg KH write:
> > Very nice stuff.  Ok, that's a good reason not to get rid of these
> > files, although they can be generated on the fly from the modules
> > themselves (like depmod does it.)
> 
> Time to resurrect modinfo? ;-)
> Didn't we plan to get rid of that, too?

Not that I know of, modinfo works great for me here :)

> If we like to use information from modules, there should be a scriptable 
> tool to extract this kind of information, otherwise it will be a bitch to 
> maintain those tools.

modinfo works well for me in this manner, it doesn't for you?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Lee Revell]

On Mon, 2005-02-14 at 09:51 +0100, Prakash Punnoor wrote:
> Paolo Ciarrocchi schrieb:
> > On Sun, 13 Feb 2005 23:06:51 -0500, Lee Revell <rlrevell@joe-job.com> wrote:
> >
> >>On Thu, 2005-02-10 at 17:16 -0800, Greg KH wrote:
> >>
> >>>All distros are trying to reduce boot time.
> >>
> >>They certainly aren't all trying very hard.  Debian and Fedora (last
> >>time I checked) do not even run the init scripts in parallel.
> >
> >
> > Is there any distro that is running the init scripts in parallel ?
> 
> Gentoo.
> 

Last I heard Gentoo does not even do it by default.

I don't see why so much effort goes into improving boot time on the
kernel side when the most obvious user space problem is ignored.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Mon, Feb 14, 2005 at 06:04:00PM -0500, Lee Revell wrote:
> On Mon, 2005-02-14 at 09:51 +0100, Prakash Punnoor wrote:
> > Paolo Ciarrocchi schrieb:
> > > On Sun, 13 Feb 2005 23:06:51 -0500, Lee Revell <rlrevell@joe-job.com> wrote:
> > >
> > >>On Thu, 2005-02-10 at 17:16 -0800, Greg KH wrote:
> > >>
> > >>>All distros are trying to reduce boot time.
> > >>
> > >>They certainly aren't all trying very hard.  Debian and Fedora (last
> > >>time I checked) do not even run the init scripts in parallel.
> > >
> > >
> > > Is there any distro that is running the init scripts in parallel ?
> > 
> > Gentoo.
> > 
> 
> Last I heard Gentoo does not even do it by default.

Gentoo doesn't do much "by default" :)  But it is an option.

> I don't see why so much effort goes into improving boot time on the
> kernel side when the most obvious user space problem is ignored.

What user space problem is that?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roland Dreier]

    Lee> I don't see why so much effort goes into improving boot time
    Lee> on the kernel side when the most obvious user space problem
    Lee> is ignored.

How much of a win is it to run init scripts in parallel?  I seem to
recall seeing tests that show that it doesn't make much difference and
may even slow things down by causing more disk seeks as various things
start up at the same time and cause reads of different files to get
interleaved.

On the other hand, hotplug is an area that real profiling of real
systems booting has identified as something that can be improved, and
Greg's hotplug-ng seems to be a step towards a measurable improvement.

 - R.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Lee Revell]

On Mon, 2005-02-14 at 15:16 -0800, Greg KH wrote:
> > I don't see why so much effort goes into improving boot time on the
> > kernel side when the most obvious user space problem is ignored.
> 
> What user space problem is that?

That init scripts with no interdependencies are run sequentially rather
than in parallel.

There was an article from IBM a while back with a neat hack that used a
parallel make to fire off groups of init scripts in parallel.  I would
expect more interest in this from the distros.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Diego Calleja]

El Mon, 14 Feb 2005 18:04:00 -0500,
Lee Revell <rlrevell@joe-job.com> escribió:

> Last I heard Gentoo does not even do it by default.
> 
> I don't see why so much effort goes into improving boot time on the
> kernel side when the most obvious user space problem is ignored.


There's stuff that it could be done in the kernel to help improving those numbers,
IMHO.

xp logs all the io done the first two minutes after booting. The next time it boots
it tries to read all those files at once so the programs will find stuff in memory
instead of having to do lots of small seeks. Some people in the linux field have
got a list of the files used at startup and they've thrown it at a "readhead" script,
which seems to help but IMHO it's somewhat "hacky" compared with the 
xp's trick. xp also does that when you start a program, it saves a log of all the
io done and it preloads it efficiently at startup - it improves "cold-cache" loading
times a _lot_. I haven't seen any alternative for that in the linux world, and
being able to keep track of al the io done by a given process would fix that (some
people has put used printk's for that, but i think it can be done better)

Also, it analyzes all those io "logs" and defragments (in background every 3 days,
and with low load without the user noticing it) the disk according to the _use_ of the
systems. Linux kernel can keep a file unfragmented, but currently there's no way
linux can do decisions like "this system starts openoffice, so I'm going to move the
binaries to another place of the disk where they'll load faster" or "when X program
uses /lib/libfoo.so it also uses /lib/libbar.so, so I'm going to put those two together
in the disk because that will avoid seeks". Kernel only can keep a single file
unfragmented, but it doesn't know about how several files must be (un)fragmented
between them. Being able to defragment things seems to be the one fix that (even
mac os x does it)

Userspace is where the problem is, but it's not going to be fixed. Ever. If
something, it's going to be worse - it's how software works. And even if you make
openoffice "fast", you still could _improve_ things with the tricks described
above. Disks are too slow, and things like demand-loading executables generate
too many small seeks, and programs can't control demand-loading so I don't
think userspace is the only with work to do.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
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

[OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Lee Revell]

On Mon, 2005-02-14 at 15:21 -0800, Roland Dreier wrote:
>     Lee> I don't see why so much effort goes into improving boot time
>     Lee> on the kernel side when the most obvious user space problem
>     Lee> is ignored.
> 
> How much of a win is it to run init scripts in parallel?  I seem to
> recall seeing tests that show that it doesn't make much difference and
> may even slow things down by causing more disk seeks as various things
> start up at the same time and cause reads of different files to get
> interleaved.
> 

This is why Windows XP reserves sapce at the beginning of the disk for
the files read during the boot process and caches copies of them there.

But, I was referring more to things like GDM not being started until all
the other init scripts are done.  Why not start it first, and let the
network initialize while the user is logging in?

> On the other hand, hotplug is an area that real profiling of real
> systems booting has identified as something that can be improved, and
> Greg's hotplug-ng seems to be a step towards a measurable improvement.

Agreed.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Tim Bird]

Lee Revell wrote:
> But, I was referring more to things like GDM not being started until all
> the other init scripts are done.  Why not start it first, and let the
> network initialize while the user is logging in?

There are a number of techniques used by CE vendors to get fast bootup
time.  Some CE products boot Linux in under 1 second.  Sony's
best Linux boot time in the lab (from power on to user space)
was 148 milliseconds, on an ARM chip (running at 200 MHZ I believe).

Every product I know of that boots in under 1 second does it
by completely eliminating RC scripts, and using a custom init
program.

For anyone interested, CELF has some resources on this topic at:
http://tree.celinuxforum.org/CelfPubWiki/BootupTimeResources

==============Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
==============

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Lee Revell]

On Mon, 2005-02-14 at 16:16 -0800, Tim Bird wrote:
> Lee Revell wrote:
> > But, I was referring more to things like GDM not being started until all
> > the other init scripts are done.  Why not start it first, and let the
> > network initialize while the user is logging in?
> 
> There are a number of techniques used by CE vendors to get fast bootup
> time.  Some CE products boot Linux in under 1 second.  Sony's
> best Linux boot time in the lab (from power on to user space)
> was 148 milliseconds, on an ARM chip (running at 200 MHZ I believe).

The reason I marked by response OT is that the time from power on to
userspace does not seem to be a big problem.  It's the amount of time
from user space to presenting a login prompt that's way too long.  My
distro (Debian) runs all the init scripts one at a time, and GDM is the
last thing that gets run.  There is just no reason for this.  We should
start X and initialize the display and get the login prompt up there
ASAP, and let the system acquire the DHCP lease and start sendmail and
apache and get the date from the NTP server *in the background while I
am logging in*.  It's not rocket science.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Kyle Moffett]

On Feb 14, 2005, at 20:17, Lee Revell wrote:
> On Mon, 2005-02-14 at 16:16 -0800, Tim Bird wrote:
>> Lee Revell wrote:
>>> But, I was referring more to things like GDM not being started until 
>>> all
>>> the other init scripts are done.  Why not start it first, and let the
>>> network initialize while the user is logging in?
>>
>> There are a number of techniques used by CE vendors to get fast bootup
>> time.  Some CE products boot Linux in under 1 second.  Sony's
>> best Linux boot time in the lab (from power on to user space)
>> was 148 milliseconds, on an ARM chip (running at 200 MHZ I believe).
>
> The reason I marked by response OT is that the time from power on to
> userspace does not seem to be a big problem.  It's the amount of time
> from user space to presenting a login prompt that's way too long.  My
> distro (Debian) runs all the init scripts one at a time, and GDM is the
> last thing that gets run.  There is just no reason for this.  We should
> start X and initialize the display and get the login prompt up there
> ASAP, and let the system acquire the DHCP lease and start sendmail and
> apache and get the date from the NTP server *in the background while I
> am logging in*.  It's not rocket science.

Such a system needs a drastically different bootup process than 
currently
exists, including the ability to specify init-script dependencies.  
(Like
for example user login via GDM (and with our setup, GDM working at all)
requires that AFS is mounted and NIS is working, which both require the
network to be available, which requires...  You can see where this is
going.  I think eventually we need a better /sbin/init, one that can use
a traditional legacy /etc/inittab file in addition to a newfangled
simultaneous boot process with lots of ways to start various kinds of
services.  Unfortunately such a system will need a _LOT_ of work and
testing to make sure it doesn't break existing setups.  Oh well, I can
dream, can't I? :-D

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Jim Crilly]

Lee Revell said the following:
> The reason I marked by response OT is that the time from power on to
> userspace does not seem to be a big problem.  It's the amount of time
> from user space to presenting a login prompt that's way too long.  My
> distro (Debian) runs all the init scripts one at a time, and GDM is the
> last thing that gets run.  There is just no reason for this.  We should
> start X and initialize the display and get the login prompt up there
> ASAP, and let the system acquire the DHCP lease and start sendmail and
> apache and get the date from the NTP server *in the background while I
> am logging in*.  It's not rocket science.

That is one of the "features" that I hate most about Windows. All you really do 
is move the delays around. For instance, my Windows machine at work is joined 
to a domain and has the Novell NetWare client installed for NDS auth (don't 
ask) so when the GINA comes up, I hit Ctrl+Alt+Del, enter my password and wait 
staring at an hourglass while the GINA waits for network connectivity to come 
up so that it can authenticate me. And even if authentication was local and I 
got logged in right away, chances are good that I have mapped drives or 
printers on the network that I will have to wait for during the login process 
anyway.

I agree boot up is too slow and that some things should be started in the 
background, but not things that are required for the main purpose of the box to 
work properly, what should be started sync and what should be async is a hard 
decision IMO. Right now I use swsusp2 to work around this, it takes less time 
to resume my session + 500M of file cache than it does to boot manually and 
start all of my apps back up, but obviously that's not a real solution.

> 
> Lee
> 

Jim.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Harald Dunkel]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

Greg KH wrote:
> On Sat, Feb 12, 2005 at 09:30:54AM +0100, Harald Dunkel wrote:
>
>>
>>If it is not possible to use klibc together with a non-Linux
>>system (e.g. FreeBSD or Mach), then I would suggest to make
>>klibc an optional kernel patch and drop it from udev and
>>hotplug.
>
>
> But it is not possible to use udev or hotplug-ng on a non-Linux system,
> right?
>

Thats not the point. The point is to remove the copy of the
klibc sources from packages like udev and hotplug-ng and
to use the existing klibc sources or binaries on the target
system instead. Just to keep it modular.

> As far as "optional kernel patch"?  What do you mean?  People are
> working on adding klibc to the main kernel tree, nothing optional about
> that.
>

I do not know the internals of klibc that much. Is it possible
to use klibc on non-Linux systems, e.g. on Mach or FreeBSD?
Maybe by adding some #ifdefs to klibc's kernel interface?

If yes, then making klibc an integrated part of the Linux
kernel source tree and dropping the independent development
tree would be a restriction to the use of klibc.


AFAIK the plan for initramfs is to move as much functionality
as possible from kernel to user space. Why not do the same
thing for the sources? Everything that is supposed to be run
in user space could be removed from the kernel source tree
and managed seperately, either in a set of userspace modules
like klibc, hotplug, udev, initramfs, etc., or in a monolithic
"userspace-tools" source tree.

Surely klibc belongs to the user space.


Regards

Harri

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Nigel Cunningham]

Ah Jim.

On Tue, 2005-02-15 at 14:38, Jim Crilly wrote:
> I agree boot up is too slow and that some things should be started in the 
> background, but not things that are required for the main purpose of the box to 
> work properly, what should be started sync and what should be async is a hard 
> decision IMO. Right now I use swsusp2 to work around this, it takes less time 
> to resume my session + 500M of file cache than it does to boot manually and 

You warmed my heart until...

> start all of my apps back up, but obviously that's not a real solution.

Why not? :> I guess you mean to the problem of slow booting in the first
place - I would agree with you there, but is there are reason why we
should have booting being the norm instead of normally suspending and
resuming, and only rebooting for new kernels/hardware/etc.

Regards,

Nigel

-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Jim Crilly]

Nigel Cunningham said the following:
> You warmed my heart until...

Good to know someone reads my email =)

> Why not? :> I guess you mean to the problem of slow booting in the first
> place - I would agree with you there, but is there are reason why we
> should have booting being the norm instead of normally suspending and
> resuming, and only rebooting for new kernels/hardware/etc.

Don't get me wrong, I would go nuts without swsusp2 on my notebook and I don't 
see why that shouldn't be a valid avenue to pursue; even for servers it doesn't 
seem like a terribly bad idea. But for me it only works on 1 out of my 4 
machines. The 3 non-working machines have their root and swap on SCSI devices 
and to top it off 2 of them are non-x86 architectures.

Another issue would be dual-booting, which a lot of people still do for some 
strange reason. At least I had noticed that Windows tends to have problems when 
filesystems it had mounted before the hibernation are altered while it's not 
running. I'm not sure if similar issues would apply to Linux, hell I'm not even 
sure if it still applies to Windows because that was so long ago that I had 
noticed.

> 
> Regards,
> 
> Nigel
> 

Jim.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Nigel Cunningham]

Hi.

On Tue, 2005-02-15 at 17:15, Jim Crilly wrote:
> Nigel Cunningham said the following:
> > You warmed my heart until...
> 
> Good to know someone reads my email =)
> 
> > Why not? :> I guess you mean to the problem of slow booting in the first
> > place - I would agree with you there, but is there are reason why we
> > should have booting being the norm instead of normally suspending and
> > resuming, and only rebooting for new kernels/hardware/etc.
> 
> Don't get me wrong, I would go nuts without swsusp2 on my notebook and I don't 
> see why that shouldn't be a valid avenue to pursue; even for servers it doesn't 
> seem like a terribly bad idea. But for me it only works on 1 out of my 4 
> machines. The 3 non-working machines have their root and swap on SCSI devices 
> and to top it off 2 of them are non-x86 architectures.

Okay. So it's a lack of hardware support then. I need to bug people to
get SCSI PM support working, and to lend me non-x86 and x86-64 some more
:>

> Another issue would be dual-booting, which a lot of people still do for some 
> strange reason. At least I had noticed that Windows tends to have problems when 
> filesystems it had mounted before the hibernation are altered while it's not 
> running. I'm not sure if similar issues would apply to Linux, hell I'm not even 
> sure if it still applies to Windows because that was so long ago that I had 
> noticed.

Suspend certainly doesn't like filesystems being mounted under it - it
writes the image without remounting ro or unmounting. I think I saw a
patch Tim had that remounted ro, but you still have to be careful as the
saved memory contains a picture of the state of superblocks and so on.

Regards,

Nigel

-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Tue, Feb 15, 2005 at 06:39:37AM +0100, Harald Dunkel wrote:
> Greg KH wrote:
> >On Sat, Feb 12, 2005 at 09:30:54AM +0100, Harald Dunkel wrote:
> >
> >>
> >>If it is not possible to use klibc together with a non-Linux
> >>system (e.g. FreeBSD or Mach), then I would suggest to make
> >>klibc an optional kernel patch and drop it from udev and
> >>hotplug.
> >
> >
> >But it is not possible to use udev or hotplug-ng on a non-Linux system,
> >right?
> >
> 
> Thats not the point. The point is to remove the copy of the
> klibc sources from packages like udev and hotplug-ng and
> to use the existing klibc sources or binaries on the target
> system instead. Just to keep it modular.

Again, my point is I'll take klibc out of the udev and hotplug-ng trees
when it is actually on people's systems because it is in the kernel
source tree.  Until that happens I'll continue to keep it in the udev
and hotplug-ng trees, ok?

> >As far as "optional kernel patch"?  What do you mean?  People are
> >working on adding klibc to the main kernel tree, nothing optional about
> >that.
> >
> 
> I do not know the internals of klibc that much. Is it possible
> to use klibc on non-Linux systems, e.g. on Mach or FreeBSD?
> Maybe by adding some #ifdefs to klibc's kernel interface?

I don't know, and I really don't care :)

> If yes, then making klibc an integrated part of the Linux
> kernel source tree and dropping the independent development
> tree would be a restriction to the use of klibc.

Huh?  You are free to take klibc and do whatever you want to with it
based on the license it has.  No one is restricting you from doing that,
right?

> AFAIK the plan for initramfs is to move as much functionality
> as possible from kernel to user space.

Yes.

> Why not do the same
> thing for the sources? Everything that is supposed to be run
> in user space could be removed from the kernel source tree
> and managed seperately, either in a set of userspace modules
> like klibc, hotplug, udev, initramfs, etc., or in a monolithic
> "userspace-tools" source tree.

Because we still want to actually be able to boot a kernel, right?  :)

Let's just get the early boot stuff building and working properly, and
then we'll worry about ripping the stuff out of the kernel tree then.

> Surely klibc belongs to the user space.

Hm, like the other things in the kernel source tree that are also only
in userspace?  :)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Gábor Lénárt]

On Mon, Feb 14, 2005 at 08:45:39PM -0500, Kyle Moffett wrote:
> >last thing that gets run.  There is just no reason for this.  We should
> >start X and initialize the display and get the login prompt up there
> >ASAP, and let the system acquire the DHCP lease and start sendmail and
> >apache and get the date from the NTP server *in the background while I
> >am logging in*.  It's not rocket science.
> 
> Such a system needs a drastically different bootup process than 
> currently
> exists, including the ability to specify init-script dependencies.  
> (Like

Ok, so see Gentoo. Exactly fits your needs, it seems ;-) Dependencies are
supported, even paralell execution of init scripts are supported by default
design (you need to change only one setting to do this, IMHO, in
/etc/conf.d/rc). So it is already solved if you talking about the paralell
execution with dependency info in init scripts ...

Also the smf ability of Solaris10 seems to be interesting, but I don't want
to talk about it, since I have no time to see it in action, I've only read
about it, so ...

- Gábor


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Sat, Feb 12, 2005 at 09:27:29PM +0500, Alexander E. Patrakov wrote:
> Greg KH wrote:
> 
> > I'd like to announce, yet-another-hotplug based userspace project:
> > linux-ng.  This collection of code replaces the existing linux-hotplug
> > package with very tiny, compiled executable programs, instead of the
> > existing bash scripts.
> 
> The ability to set up userspace handlers for certain devices via *.usermap
> files (see SANE and gphoto2 for basic "chown and chmod a file
> in /proc/bus/usb" examples) was lost.

Yes.  That stuff is a mess and I'm glad to get rid of it :)

> Is this functionality planned to be restored in hotplug-ng?

Nope.

> Or is it the responsibility of SANE and gphoto2 maintainers to adapt
> to this change e.g. by providing additional files for
> /etc/hotplug.d/usb instead?

Yes, it's easier for programs to add their own hooks into
/etc/hotplug.d/ directory than for them to modify the usermap files,
correct?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Christian Zoz]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

Hi Greg,

the pci alias string does never match. Here is a patch.

-- 

ciao, christian

睡眠不足はいい仕事の敵だ。

[-- Attachment #2: hotplug-ng-001.pci_id.patch --]
[-- Type: text/plain, Size: 931 bytes --]

--- hotplug-ng-001.orig/module_pci.c	2005-02-11 00:40:02.000000000 +0100
+++ hotplug-ng-001.2nd/module_pci.c	2005-02-11 13:48:03.000000000 +0100
@@ -60,10 +60,10 @@
 	interface = (unsigned char)class;
 	
 	strcpy(pci_string, "pci:");
-	sprintf(pci_string + strlen(pci_string), "v%04X", vendor);
-	sprintf(pci_string + strlen(pci_string), "d%04X", device);
-	sprintf(pci_string + strlen(pci_string), "sv%04X", subvendor);
-	sprintf(pci_string + strlen(pci_string), "sd%04X", subdevice);
+	sprintf(pci_string + strlen(pci_string), "v%08X", vendor);
+	sprintf(pci_string + strlen(pci_string), "d%08X", device);
+	sprintf(pci_string + strlen(pci_string), "sv%08X", subvendor);
+	sprintf(pci_string + strlen(pci_string), "sd%08X", subdevice);
 	sprintf(pci_string + strlen(pci_string), "bc%02X", baseclass);
 	sprintf(pci_string + strlen(pci_string), "sc%02X", subclass);
 	sprintf(pci_string + strlen(pci_string), "i%02X", interface);

Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Paolo Ciarrocchi]

On Mon, 14 Feb 2005 18:45:20 -0500, Lee Revell <rlrevell@joe-job.com> wrote:
> On Mon, 2005-02-14 at 15:21 -0800, Roland Dreier wrote:
> >     Lee> I don't see why so much effort goes into improving boot time
> >     Lee> on the kernel side when the most obvious user space problem
> >     Lee> is ignored.
> >
> > How much of a win is it to run init scripts in parallel?  I seem to
> > recall seeing tests that show that it doesn't make much difference and
> > may even slow things down by causing more disk seeks as various things
> > start up at the same time and cause reads of different files to get
> > interleaved.
> >
> 
> This is why Windows XP reserves sapce at the beginning of the disk for
> the files read during the boot process and caches copies of them there.
> 
> But, I was referring more to things like GDM not being started until all
> the other init scripts are done.  Why not start it first, and let the
> network initialize while the user is logging in?
> 
> > On the other hand, hotplug is an area that real profiling of real
> > systems booting has identified as something that can be improved, and
> > Greg's hotplug-ng seems to be a step towards a measurable improvement.

Did anyone measure the improvement ?

-- 
Paolo <paolo dot ciarrocchi at gmail dot com>
msn: paolo407@hotmail.com
hello: ciarrop


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Paolo Ciarrocchi]

On Tue, 15 Feb 2005 08:32:22 +0100, Gábor Lénárt <lgb@lgb.hu> wrote:
> On Mon, Feb 14, 2005 at 08:45:39PM -0500, Kyle Moffett wrote:
> > >last thing that gets run.  There is just no reason for this.  We should
> > >start X and initialize the display and get the login prompt up there
> > >ASAP, and let the system acquire the DHCP lease and start sendmail and
> > >apache and get the date from the NTP server *in the background while I
> > >am logging in*.  It's not rocket science.
> >
> > Such a system needs a drastically different bootup process than
> > currently
> > exists, including the ability to specify init-script dependencies.
> > (Like
> 
> Ok, so see Gentoo. Exactly fits your needs, it seems ;-) Dependencies are
> supported, even paralell execution of init scripts are supported by default
> design (you need to change only one setting to do this, IMHO, in
> /etc/conf.d/rc). So it is already solved if you talking about the paralell
> execution with dependency info in init scripts ...

So... why is Gentoo the only distro the uses parallel execution of
init scripts ?

-- 
Paolo <paolo dot ciarrocchi at gmail dot com>
msn: paolo407@hotmail.com
hello: ciarrop


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Helge Hafting]

Kyle Moffett wrote:

> On Feb 14, 2005, at 20:17, Lee Revell wrote:
>
>> On Mon, 2005-02-14 at 16:16 -0800, Tim Bird wrote:
>>
>>> Lee Revell wrote:
>>>
>>>> But, I was referring more to things like GDM not being started 
>>>> until all
>>>> the other init scripts are done.  Why not start it first, and let the
>>>> network initialize while the user is logging in?
>>>
>>>
>>> There are a number of techniques used by CE vendors to get fast bootup
>>> time.  Some CE products boot Linux in under 1 second.  Sony's
>>> best Linux boot time in the lab (from power on to user space)
>>> was 148 milliseconds, on an ARM chip (running at 200 MHZ I believe).
>>
>>
>> The reason I marked by response OT is that the time from power on to
>> userspace does not seem to be a big problem.  It's the amount of time
>> from user space to presenting a login prompt that's way too long.  My
>> distro (Debian) runs all the init scripts one at a time, and GDM is the
>> last thing that gets run.  There is just no reason for this.  We should
>> start X and initialize the display and get the login prompt up there
>> ASAP, and let the system acquire the DHCP lease and start sendmail and
>> apache and get the date from the NTP server *in the background while I
>> am logging in*.  It's not rocket science.
>
>
> Such a system needs a drastically different bootup process than currently
> exists, including the ability to specify init-script dependencies.  (Like

The init-script dependencies are specifies already - at least on debian.
Look at the most used runlevel, ls /etc/rc2.d:

S10sysklogd@
S11klogd
S14ppp
S18portmap
S19slapd
S20alsa
S20cupsys
S20dhcp3-server
S20exim
...
The numbers specify ordering constraint, low numbers must start before 
high numbers.
But plenty of scripts have no interdependencies, I have 18 scripts 
numbered S20.
Today they start sequentially anyway, in alphabetical order.  Several of 
them simply
wait for hardware, which could be done in parallel.  So parallel 
execution would be a win.
One could always have a user-settable limit on how much to run in 
parallel, to help
out those low-memory machines. 

> for example user login via GDM (and with our setup, GDM working at all)
> requires that AFS is mounted and NIS is working, which both require the
> network to be available, which requires...  You can see where this is

Yes.  I don't think the X system will start before other things in a 
standard
installation, precisely because it *might* need the network and a bunch 
of other
things to validate the user.  So most of the gain will come from the 
parallel starting
of earlier scripts.
I think one can safely say that the xserver it won't need web, email
or the printer subsystems to get up though, and that could also save 
some time.

> going.  I think eventually we need a better /sbin/init, one that can use
> a traditional legacy /etc/inittab file in addition to a newfangled
> simultaneous boot process with lots of ways to start various kinds of
> services.  Unfortunately such a system will need a _LOT_ of work and
> testing to make sure it doesn't break existing setups.  Oh well, I can
> dream, can't I? :-D

It isn't all that hard.  An init with one change - scripts with the same 
number
runs in parallel instead of sequentially. (And possibly some 
configurable limit
on parallel scripts).  Then the rest of the work lies in an efficient 
and correct numbering of those
scripts.  The paranoid can renumber them so they run in the same
order as they used to.  Most people can use the existing numbering, 
perhaps they
discover an ordering bug or two which is trivially fixed using "mv" to 
renumber scripts.
And the more daring can renumber their scripts for maximum parallelism.

Even with today's system the goal of starting X early is achievable.  If you
know that X doesn't need the network on _your_ machine - renumber it to
start really early.  The modification is easy enough to do. :-)

If it still starts slow, swithc to a light session manager (like xdm) and
a lightweight window manager that doesn't bring in kde or gnome.

Helge Hafting





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process

[Bernd Petrovitsch]

On Tue, 2005-02-15 at 09:34 +0100, Paolo Ciarrocchi wrote:
[...]
> So... why is Gentoo the only distro the uses parallel execution of
> init scripts ?

Because no other distro bothered to implement it.

Apart from that we as quite far off-topic for LKML since this has
nothing to do with kernel.
The only reason getting this on-topic is to try to get the best SWSUSP
support in the kernel so one simply does not need this.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Bernd Petrovitsch]

On Tue, 2005-02-15 at 09:55 +0100, Helge Hafting wrote:
[...]
> The init-script dependencies are specifies already - at least on debian.

These are not dependencies but "only" the sequence of startup (and it is
not only Debian but also Fedora/RedHat, SuSE, Mandrake and probably all
except Gentoo).
Yuo get a much stricter ordering and sorting (and thus much simpler to
implement in a shell script).

> Look at the most used runlevel, ls /etc/rc2.d:
> 
> S10sysklogd@
> S11klogd
> S14ppp
> S18portmap
> S19slapd
> S20alsa
> S20cupsys
> S20dhcp3-server
> S20exim
> ...
> The numbers specify ordering constraint, low numbers must start before 
> high numbers.
> But plenty of scripts have no interdependencies, I have 18 scripts 
> numbered S20.

This would be a win (especially if the numbers are tweked to tune this)
with a relatively small effort.
However for real dependencies and parallelism you want the info similar
to creat a Makefile from it (i.e. the explicit dependency from service X
to service Y). As a consequence you can get rid of the numbers (since
they are not needed any more).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Alexander E. Patrakov]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

On Tuesday 15 February 2005 12:34, Greg KH wrote:
> On Sat, Feb 12, 2005 at 09:27:29PM +0500, Alexander E. Patrakov wrote:
> > Greg KH wrote:
> > > I'd like to announce, yet-another-hotplug based userspace project:
> > > hotplug-ng.  This collection of code replaces the existing linux-hotplug
> > > package with very tiny, compiled executable programs, instead of the
> > > existing bash scripts.
> >
> > The ability to set up userspace handlers for certain devices via
> > *.usermap files (see SANE and gphoto2 for basic "chown and chmod a file
> > in /proc/bus/usb" examples) was lost.
>
> Yes.  That stuff is a mess and I'm glad to get rid of it :)
>
> > Is this functionality planned to be restored in hotplug-ng?
>
> Nope.
>
> > Or is it the responsibility of SANE and gphoto2 maintainers to adapt
> > to this change e.g. by providing additional files for
> > /etc/hotplug.d/usb instead?
>
> Yes, it's easier for programs to add their own hooks into
> /etc/hotplug.d/ directory than for them to modify the usermap files,
> correct?

Indeed. How about including the hook for SANE (attached, place it 
in /etc/hotplug.d/usb/libusbscanner.hotplug) into the next release of 
hotplug-ng as an example? Or, even better, in the next SANE version?

It differs a lot from the current version of the script. Instead of 
duplicating knowledge in several places including the usermap file, this 
script relies on the output from sane-find-scanner.

Sorry for not providing gphoto2 hook. I don't have a digital camera.

-- 
Alexander E. Patrakov

[-- Attachment #2: libusbscanner.hotplug --]
[-- Type: application/x-shellscript, Size: 635 bytes --]

Re: [sane-devel] Re: [ANNOUNCE] hotplug-ng 001 release

[Julien BLACHE]

"Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:

Hi,

> Indeed. How about including the hook for SANE (attached, place it 
> in /etc/hotplug.d/usb/libusbscanner.hotplug) into the next release of 
> hotplug-ng as an example? Or, even better, in the next SANE version?
>
> It differs a lot from the current version of the script. Instead of 
> duplicating knowledge in several places including the usermap file, this 
> script relies on the output from sane-find-scanner.

Eeeek. sane-find-scanner can potentially report something which is not
a USB scanner as a scanner, so it's not really a good idea.

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb@jblache.org>                                  GPG KeyID 0xF5D65169


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Helge Hafting]

Bernd Petrovitsch wrote:

>On Tue, 2005-02-15 at 09:55 +0100, Helge Hafting wrote:
>[...]
>  
>
>>The init-script dependencies are specifies already - at least on debian.
>>    
>>
>
>These are not dependencies but "only" the sequence of startup (and it is
>not only Debian but also Fedora/RedHat, SuSE, Mandrake and probably all
>except Gentoo).
>  
>
Yes, it is a sequence.  It it derived from real dependencies though,
where nondependent stuff have the same number.

>Yuo get a much stricter ordering and sorting (and thus much simpler to
>implement in a shell script).
>  
>
Correct.

>This would be a win (especially if the numbers are tweked to tune this)
>with a relatively small effort.
>However for real dependencies and parallelism you want the info similar
>to creat a Makefile from it (i.e. the explicit dependency from service X
>to service Y). As a consequence you can get rid of the numbers (since
>they are not needed any more).
>  
>
Now that is a really good idea.  Init could simply run "make -j init2" to
enter runlevel 2.  A suitable makefile would list all dependencies, and
of course the targets needed for "init2", "init3" and so on.

It might not be that much work either.  Parallel make exists already, 
and the
first attempt at a makefile could simply implement the current sequence that
is known to work. Then the tweaking comes. :-)

Helge Hafting

 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Paulo Marques]

Helge Hafting wrote:
> Now that is a really good idea.  Init could simply run "make -j init2" to
> enter runlevel 2.  A suitable makefile would list all dependencies, and
> of course the targets needed for "init2", "init3" and so on.
> 
> It might not be that much work either.  Parallel make exists already, 
> and the
> first attempt at a makefile could simply implement the current sequence 
> that
> is known to work. Then the tweaking comes. :-)

Someone already mentioned this work before on this thread. I just 
googled for it and found the link:

http://www-106.ibm.com/developerworks/linux/library/l-boot.html?ca=dgr-lnxw04BootFaster

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Bernd Petrovitsch]

On Tue, 2005-02-15 at 14:20 +0100, Helge Hafting wrote:
> Bernd Petrovitsch wrote:
> >On Tue, 2005-02-15 at 09:55 +0100, Helge Hafting wrote:
[...]
> >These are not dependencies but "only" the sequence of startup (and it is
> >not only Debian but also Fedora/RedHat, SuSE, Mandrake and probably all
> >except Gentoo).
> >  
> Yes, it is a sequence.  It it derived from real dependencies though,
> where nondependent stuff have the same number.

Yes, of course. Sorry if that wasn't clear.

> >However for real dependencies and parallelism you want the info similar
> >to creat a Makefile from it (i.e. the explicit dependency from service X
> >to service Y). As a consequence you can get rid of the numbers (since
> >they are not needed any more).
> >  
> Now that is a really good idea.  Init could simply run "make -j init2" to

Actually I just used it to illustrate the idea.
As with Gentoo, I'm not a guru there so other people must comment if
Gentoo actually starts services in parallel.

> enter runlevel 2.  A suitable makefile would list all dependencies, and
> of course the targets needed for "init2", "init3" and so on.
> 
> It might not be that much work either.  Parallel make exists already, 
> and the
> first attempt at a makefile could simply implement the current sequence that
> is known to work. Then the tweaking comes. :-)

You just have to cope with the potentially parallel output reliably
especially in error cases (which is IMHO basically the most work).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Stefan Seyfried]

Lee Revell wrote:

> That init scripts with no interdependencies are run sequentially rather
> than in parallel.
> 
> There was an article from IBM a while back with a neat hack that used a
> parallel make to fire off groups of init scripts in parallel.  I would
> expect more interest in this from the distros.

You can boot a SUSE 9.2 with parallel init scripts (default AFAIR),
sequential init scripts and with a Makefile based solution. "Normal"
(not Makefile based) parallel booting is possible much longer on SUSE,
at least since 9.0 IIRC.
And guess what? "Parallel booting" alone, regardless of the mechanism
does not make much of a difference for the boot time.

Stefan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Lee Revell]

On Tue, 2005-02-15 at 01:15 -0500, Jim Crilly wrote:
> Another issue would be dual-booting, which a lot of people still do for some 
> strange reason.

Um, to reverse engineer Windows drivers?

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Lee Revell]

On Tue, 2005-02-15 at 00:43 +0100, Diego Calleja wrote:
> There's stuff that it could be done in the kernel to help improving those numbers,
> IMHO.
> 
> xp logs all the io done the first two minutes after booting. The next time it boots
> it tries to read all those files at once so the programs will find stuff in memory
> instead of having to do lots of small seeks.

Thanks for the detailed explanation.  ISTR hearing that some of the
distros are working on similar solutions.  Now this would be a big win,
as anyone who has seen how much faster XP boots than Win2K can tell you.
And would certainly require kernel support.

Of course resuming from suspend will always be faster than booting but
for the forseeable future we will have to reboot from time to time.  And
XP's boot time currently is way, way better than ours.  FWIW, OSX still
takes forever to boot so we are not the only ones with this problem.

I wonder if XP's solution is patented.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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

Optimizing disk-I/O [was Re: [ANNOUNCE] hotplug-ng 001 release]

[Linas Vepstas]

On Tue, Feb 15, 2005 at 12:43:29AM +0100, Diego Calleja was heard to remark:
> 
> Also, it analyzes all those io "logs" and defragments 

I dislike hearing/reading about what XP does, since its probably patented,
and I don't want that shadow hanging over Linux.

I assume that the following simple idea, obvious to any practictioner 
versed in the state of the art, is not patented or patentable:

> linux can do decisions like "this system starts openoffice, so I'm going to move the
> binaries to another place of the disk where they'll load faster" or "when X program
> uses /lib/libfoo.so it also uses /lib/libbar.so, so I'm going to put those two together
> in the disk because that will avoid seeks". 

Now I like this idea. It need not have anything to do with startup,
or with any particular program or distro whatsoever.  Rather, one 
would have a daemon keeping track of disk i/o patterns, and constantly 
trying to figure out if there is a rearrangement of the sectors on disk
that would minimize i/o seeks based on past uasge. 

The optimization routine could be some simulated annealing or 
genetic algorithm or whatever whiz-bang technique someone is into.
Just keep it running in the background, low priority, constantly...
This would give you the best "time weighted" disk access performance,
although it would potentially hurt boot times, since most users spend
most of thier time doing disk access other than booting ... 

--linas



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[kernel]

On Tue, 2005-02-15 at 10:15, Stefan Seyfried wrote:
> You can boot a SUSE 9.2 with parallel init scripts (default AFAIR),
> sequential init scripts and with a Makefile based solution. "Normal"
> (not Makefile based) parallel booting is possible much longer on SUSE,
> at least since 9.0 IIRC.
> And guess what? "Parallel booting" alone, regardless of the mechanism
> does not make much of a difference for the boot time.
> 

My experience has been that hardware detection is what slows boot
process.  I've tested on various distros, Red Hat Linux, Slackware
Linux, SUSE, and Debian.

Starting services never seems to take any time (noticeable time).  But
when it lands on detecting hardware, that's where the time is chewed. 
Typically with hotplug (all using 2.4 kernels) it's about 30 seconds,
which is the same as the rest of the boot process in my testing lab. 
1394, USB, and PCMCIA seem to be the slowest (because when I remove
these devices or turn off detection of these types boot time is *much*
faster).


Two things that I believe should be addressed;

1) Speeding up boot time (even if that means moving some hardware
detection and recognition to after login)

-and-

2) Proper identification of filesystem types.  Would love to have an
agreed upon by majority change that would change the mounting of
filesystems (identifying FS TYPE) to be more accurate.  


regards,

-fd



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: Optimizing disk-I/O [was Re: [ANNOUNCE] hotplug-ng 001 release]

[Adam Goode]

Mac OS X has a similar thing, with a pretty simple description of how
they do it:

http://developer.apple.com/technotes/tn/tn1150.html#HotFile



Adam



On Tue, 2005-02-15 at 13:56 -0600, Linas Vepstas wrote:
> On Tue, Feb 15, 2005 at 12:43:29AM +0100, Diego Calleja was heard to remark:
> > 
> > Also, it analyzes all those io "logs" and defragments 
> 
> I dislike hearing/reading about what XP does, since its probably patented,
> and I don't want that shadow hanging over Linux.
> 
> I assume that the following simple idea, obvious to any practictioner 
> versed in the state of the art, is not patented or patentable:
> 
> > linux can do decisions like "this system starts openoffice, so I'm going to move the
> > binaries to another place of the disk where they'll load faster" or "when X program
> > uses /lib/libfoo.so it also uses /lib/libbar.so, so I'm going to put those two together
> > in the disk because that will avoid seeks". 
> 
> Now I like this idea. It need not have anything to do with startup,
> or with any particular program or distro whatsoever.  Rather, one 
> would have a daemon keeping track of disk i/o patterns, and constantly 
> trying to figure out if there is a rearrangement of the sectors on disk
> that would minimize i/o seeks based on past uasge. 
> 
> The optimization routine could be some simulated annealing or 
> genetic algorithm or whatever whiz-bang technique someone is into.
> Just keep it running in the background, low priority, constantly...
> This would give you the best "time weighted" disk access performance,
> although it would potentially hurt boot times, since most users spend
> most of thier time doing disk access other than booting ... 
> 
> --linas
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Diego Calleja]

El Tue, 15 Feb 2005 14:51:06 -0500,
Lee Revell <rlrevell@joe-job.com> escribió:


> Of course resuming from suspend will always be faster than booting but
> for the forseeable future we will have to reboot from time to time.  And
> XP's boot time currently is way, way better than ours.  FWIW, OSX still
> takes forever to boot so we are not the only ones with this problem.


What I wonder is if we can have a "process-to-disk" thing and use it to improve
other things. Some OSs implement this (DFbsd, for one), but I think we could
use it to do some cool things, ie: instead of closing gnome and restarting all
the apps when you login again, you could do something like "when you're
closing gnome, dump all the process' images to disk and restart all the process
when you login again". This way your desktop would be *always* in the
same state you left it (including things like the text buffer in your terminal). You
could use it to speed up some things ej: instead of loading openoffice, load a saved
image of a void document. Of course there're lots of problems, like what happens
if you change a file which was being used by a suspended process, disconnection
between app <-> xserver (x folks are working on thinks like that because of wireless
connections i think) , what happens if you update a library that a image is supposed to
use, can users "restart" images or just only root, etc but i think it'd be interesting to
discuss if it's feasible

(in the X world there's already some "signal" sent to programs, but if we were able
to do it by "sending a process' image to disk" it'd be much easier and cleaner IMHO)


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On Tue, 15 Feb 2005 14:51:06 EST, Lee Revell said:

> I wonder if XP's solution is patented.

If it is, IBM's OS/360 and OS/VS1 and MVS had prior art way back in the 70's.
There were *plenty* of products that would look at the system call usage and
spit out an ordered load list for SYS1.LINKLIB and SYS1.LPALIB - so the idea of
machine-optimizing the list of things to cache for a fast startup is *not*
new.

I'd not be surprised to find out that somebody did something like that on the 7094 ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Optimizing disk-I/O [was Re: [ANNOUNCE] hotplug-ng 001 release]

[Diego Calleja]

El Tue, 15 Feb 2005 15:46:56 -0500,
Adam Goode <adam@evdebs.org> escribió:

> Mac OS X has a similar thing, with a pretty simple description of how
> they do it:
> 
> http://developer.apple.com/technotes/tn/tn1150.html#HotFile

Also all those things are part of darwin i think (or IOW, we can look at how they
did it)


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
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: Optimizing disk-I/O [was Re: [ANNOUNCE] hotplug-ng 001 release]

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Tue, 15 Feb 2005 13:56:14 CST, Linas Vepstas said:

> Now I like this idea. It need not have anything to do with startup,
> or with any particular program or distro whatsoever.  Rather, one 
> would have a daemon keeping track of disk i/o patterns, and constantly 
> trying to figure out if there is a rearrangement of the sectors on disk
> that would minimize i/o seeks based on past uasge. 

More prior art - a company called FDR made a disk compactor product for IBM's
OS series, and I seem to remember a SHARE (IBM mainframe user group) tape that
had a program to read the I/O trace table and generate an optimal "what goes
where" command stream for FDR's software.  Again a late 70s to early 80s thing.

(Probably not enough to be "prior art" by itself, but certainly goes towards
the "obviousness to a practitioner in the field" criteria - if *I* knew about it
as a junior sysadmin at a college in middle-of-nowhere upstate NY knew about
it in 1983.. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Chris Friesen]

Diego Calleja wrote:
> Of course there're lots of problems, like what happens
> if you change a file which was being used by a suspended process, 

That one is easy.  Store a checksum of the file in use when you go to 
sleep  If on wakeup the checksum is different, pop up a window that says 
"the file *foo* has been modified by another application, do you want to 
reload?".

 > what happens if you update a library that a image is supposed to
> use

Same as updating it on a running system.  Don't do that unless you 
really know what you're doing.

Chris


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Mon, Feb 14, 2005 at 02:42:08PM -0800, Greg KH wrote:
> You are completly correct, I love your kernel patch.

I'm glad you like it.  In case you're interested, I'll send a patch for
the SCSI case in the followup mail.

Meanwhile let me speculate a bit about another potential use of this
envirnonment variable.  E.g. here's a slightly modified /sbin/hotplug
from hotplug-2004_09_23:

DIR="/etc/hotplug.d"
DEVDIR="${DIR}/$1/${MODNAME#*:}"

for I in "${DIR}/$1/"* "${DIR}/"default/*.hotplug ; do
	if [ -f "$I" ]; then
		case "$I" in
		  *.hotplug)
			[ -x "$I" ] && "$I" $1
			;;
		esac
	elif [ -d "$I" ]; then
		case "$DEVDIR" in
		  $I)
			for J in "$I"/*.hotplug; do
				[ -f "$J" -a  -x "$J" ] && "$J" $1
			done
			;;
		esac
	fi
done

exit 1

It extends the hotplug multiplexor to dispatch the hotplug scripts in
the hotplug.d/bus directory and its subdirectories matching the $MODNAME
(with the bus: prefix stripped).

The subdirectory names would be shell patterns themselves.  (This might
be somewhat counterintuitive because normally you want all names that
match a pattern, but here you want all patterns (at the same time
directory names) that match the $MODNAME.)  E.g. if someone wants a
hotplug script to be run only for USB devices with vendor ID 0x1234 and
product ID 0xABCD he would put his script under
/etc/hotplug.d/usb/v1234bABCD\*/.

This way it can replace that *map thing without the need to start
_every_ hotplug script just to see most of them exit without doing
anything because they don't match the device.

The script above works even with ash from klibc-0.198; it should be
fairly easy to implement the same model in the binary hotplug, provided
fnmatch is added to klibc.

BTW this will probably render "MODNAME" inappropriate; DEVALIAS or
something like that would be better.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

Below is the promised patch dealing with scsi module loading (can't
compile-test it at the moment, sorry).  It has two caveats (I suspect
you'll find more :) :

 1) I'm not particularly certain about the "scsi-type-" prefix: it may
    resemble cases where request_module() is used;

 2) TYPE_* macros in include/linux/scsi.h are in hex and can't be
    conveniently __stringify()-ed, so I've hardcoded the values and
    inserted comments next to them referring to those macros.

It handles only st, sd_mod and sr_mod cases (as
hotplug-ng-001/module_scsi.c did).  Are there any other?

Cheers,
  Roman.

diff -ruNp -x '*~' linux-2.6.11-rc4.hotplug.orig/drivers/scsi/scsi_sysfs.c linux-2.6.11-rc4.hotplug/drivers/scsi/scsi_sysfs.c
--- linux-2.6.11-rc4.hotplug.orig/drivers/scsi/scsi_sysfs.c	2005-02-13 06:05:41.000000000 +0300
+++ linux-2.6.11-rc4.hotplug/drivers/scsi/scsi_sysfs.c	2005-02-16 04:19:07.000000000 +0300
@@ -202,9 +202,29 @@ static int scsi_bus_match(struct device 
 	return (sdp->inq_periph_qual = SCSI_INQ_PQ_CON)? 1: 0;
 }
 
+#ifdef CONFIG_HOTPLUG
+static int scsi_hotplug(struct device *dev, char **envp,
+			int num_envp, char *buffer, int buffer_size)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	int i = 0;
+	int length = 0;
+
+	if (add_hotplug_env_var(envp, num_envp, &i, buffer, buffer_size, &length,
+				"MODNAME=scsi-type-%d", sdev->type))
+		return -ENOMEM;
+
+	envp[i] = NULL;
+	return 0;
+}
+#endif
+
 struct bus_type scsi_bus_type = {
         .name		= "scsi",
         .match		= scsi_bus_match,
+#ifdef CONFIG_HOTPLUG
+	.hotplug	= scsi_hotplug,
+#endif
 };
 
 int scsi_sysfs_register(void)
diff -ruNp -x '*~' linux-2.6.11-rc4.hotplug.orig/drivers/scsi/sd.c linux-2.6.11-rc4.hotplug/drivers/scsi/sd.c
--- linux-2.6.11-rc4.hotplug.orig/drivers/scsi/sd.c	2005-02-13 06:07:01.000000000 +0300
+++ linux-2.6.11-rc4.hotplug/drivers/scsi/sd.c	2005-02-16 04:18:47.000000000 +0300
@@ -1653,6 +1653,8 @@ static void __exit exit_sd(void)
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Eric Youngdale");
 MODULE_DESCRIPTION("SCSI disk (sd) driver");
+MODULE_ALIAS("scsi-type-0");	/*	TYPE_DISK	*/
+MODULE_ALIAS("scsi-type-7");	/*	TYPE_MOD	*/
 
 module_init(init_sd);
 module_exit(exit_sd);
diff -ruNp -x '*~' linux-2.6.11-rc4.hotplug.orig/drivers/scsi/sr.c linux-2.6.11-rc4.hotplug/drivers/scsi/sr.c
--- linux-2.6.11-rc4.hotplug.orig/drivers/scsi/sr.c	2005-02-13 06:08:04.000000000 +0300
+++ linux-2.6.11-rc4.hotplug/drivers/scsi/sr.c	2005-02-16 04:23:25.000000000 +0300
@@ -956,6 +956,9 @@ static void __exit exit_sr(void)
 	unregister_blkdev(SCSI_CDROM_MAJOR, "sr");
 }
 
+MODULE_ALIAS("scsi-type-4");	/*	TYPE_WORM	*/
+MODULE_ALIAS("scsi-type-5");	/*	TYPE_ROM	*/
+
 module_init(init_sr);
 module_exit(exit_sr);
 MODULE_LICENSE("GPL");
diff -ruNp -x '*~' linux-2.6.11-rc4.hotplug.orig/drivers/scsi/st.c linux-2.6.11-rc4.hotplug/drivers/scsi/st.c
--- linux-2.6.11-rc4.hotplug.orig/drivers/scsi/st.c	2005-02-13 06:06:55.000000000 +0300
+++ linux-2.6.11-rc4.hotplug/drivers/scsi/st.c	2005-02-16 04:26:28.000000000 +0300
@@ -4090,6 +4090,8 @@ static void __exit exit_st(void)
 	printk(KERN_INFO "st: Unloaded.\n");
 }
 
+MODULE_ALIAS("scsi-type-1");	/*	TYPE_TAPE	*/
+
 module_init(init_st);
 module_exit(exit_st);
 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

On Feb 16, Roman Kagan <rkagan@mail.ru> wrote:

> It handles only st, sd_mod and sr_mod cases (as
> hotplug-ng-001/module_scsi.c did).  Are there any other?
There is the open issue of which component should load sg.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Wed, Feb 16, 2005 at 02:07:52PM +0300, Roman Kagan wrote:
>  2) TYPE_* macros in include/linux/scsi.h are in hex and can't be

Ups, should've been include/scsi/scsi.h.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Wed, Feb 16, 2005 at 12:11:06PM +0100, Marco d'Itri wrote:
> On Feb 16, Roman Kagan <rkagan@mail.ru> wrote:
> 
> > It handles only st, sd_mod and sr_mod cases (as
> > hotplug-ng-001/module_scsi.c did).  Are there any other?
> There is the open issue of which component should load sg.

Yep, I've just reproduced what was in hotplug-ng-001/module_scsi.c,
which didn't load sg at all.  Dunno if it conflicts with st, sd and sr,
but if it doesn't we can use "scsi-type-*" alias for sg and load it
always.  Otherwise we can explicitly list all TYPE_* which are handled
by neither of st, sd, and sr.

  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Kay Sievers]

On Wed, Feb 16, 2005 at 01:51:17PM +0300, Roman Kagan wrote:
> Meanwhile let me speculate a bit about another potential use of this
> envirnonment variable.  E.g. here's a slightly modified /sbin/hotplug
...
> It extends the hotplug multiplexor to dispatch the hotplug scripts in
> the hotplug.d/bus directory and its subdirectories matching the $MODNAME
> (with the bus: prefix stripped).
> 
> The subdirectory names would be shell patterns themselves.  (This might
> be somewhat counterintuitive because normally you want all names that
> match a pattern, but here you want all patterns (at the same time
> directory names) that match the $MODNAME.)  E.g. if someone wants a
> hotplug script to be run only for USB devices with vendor ID 0x1234 and
> product ID 0xABCD he would put his script under
> /etc/hotplug.d/usb/v1234bABCD\*/.
> 
> This way it can replace that *map thing without the need to start
> _every_ hotplug script just to see most of them exit without doing
> anything because they don't match the device.

I like something like this a lot.

> The script above works even with ash from klibc-0.198; it should be
> fairly easy to implement the same model in the binary hotplug, provided
> fnmatch is added to klibc.

Be aware that we need this functionality inside of udev too, cause udev/udevd
manages the hotplug events at least on Gentoo, Fedora and SUSE, and the
later two can never use the tiny multiplexer, cause these systems do not
support installations without udev.
And we already have a something like fnmatch in udev, which compiles nicely
with klibc. :)

It may also solve the current trouble with the udev dev.d/ scripts. We need to
execute a tty script to support real serial devices, but surely don't want to
fork a useless shell for the hundreds of real ttys. We may even consider
to move the dev.d/ scripts over to hotplug.d/ to have only a single
source of event handling and device matching.

I really like to see all this happen as it seems to make things a whole lot
easier than today.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Wed, Feb 16, 2005 at 01:37:41PM +0100, Kay Sievers wrote:
> Be aware that we need this functionality inside of udev too, cause udev/udevd
> manages the hotplug events at least on Gentoo, Fedora and SUSE, and the
> later two can never use the tiny multiplexer, cause these systems do not
> support installations without udev.

Is there any reason why the hotplug multiplexer part of udev should have
different codebase from the tiny hotplug?

> And we already have a something like fnmatch in udev, which compiles nicely
> with klibc. :)

Do you mean namedev.c:strcmp_pattern() ?  That should do I think.  Then
it'll probably need udev_utils.c:call_foreach_file() to allow one-level
recursion into the subdirectories and to accept a matcher for their
names as an extra parameter.

Alternatively, one can put a $DEVALIAS multiplexer script in each of the bus
directories in /etc/hotplug.d, so that the main hotplug multiplexer is
unchanged.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Kay Sievers]

On Wed, Feb 16, 2005 at 06:17:10PM +0300, Roman Kagan wrote:
> On Wed, Feb 16, 2005 at 01:37:41PM +0100, Kay Sievers wrote:
> > Be aware that we need this functionality inside of udev too, cause udev/udevd
> > manages the hotplug events at least on Gentoo, Fedora and SUSE, and the
> > later two can never use the tiny multiplexer, cause these systems do not
> > support installations without udev.
> 
> Is there any reason why the hotplug multiplexer part of udev should have
> different codebase from the tiny hotplug?

No, but anyway I don't see any real use case for that program at all. You have
all the random hotplug event order and the bad sysfs timing problems which is
definitely not what you want to have in a "next generation"-hotplug. :)

And with your proposed $DEVALIAS changes the hotplug-ng gets so small that it
may be easier for it to live in the udev tree?

> > And we already have a something like fnmatch in udev, which compiles nicely
> > with klibc. :)
> 
> Do you mean namedev.c:strcmp_pattern() ?  That should do I think.  Then
> it'll probably need udev_utils.c:call_foreach_file() to allow one-level
> recursion into the subdirectories and to accept a matcher for their
> names as an extra parameter.

Sounds good to me. We may change the suffix parameter to accept a match
string instead? And we change this function to return a sorted list of files
which are matching.

> Alternatively, one can put a $DEVALIAS multiplexer script in each of the bus
> directories in /etc/hotplug.d, so that the main hotplug multiplexer is
> unchanged.

Hmm, I prefer the first one.

Kay


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Willem Riede]

On 02/16/2005 06:07:52 AM, Roman Kagan wrote:
> Below is the promised patch dealing with scsi module loading (can't
> compile-test it at the moment, sorry).  It has two caveats (I suspect
> you'll find more :) :
> 
>  1) I'm not particularly certain about the "scsi-type-" prefix: it may
>     resemble cases where request_module() is used;
> 
>  2) TYPE_* macros in include/linux/scsi.h are in hex and can't be
>     conveniently __stringify()-ed, so I've hardcoded the values and
>     inserted comments next to them referring to those macros.
> 
> It handles only st, sd_mod and sr_mod cases (as
> hotplug-ng-001/module_scsi.c did).  Are there any other?

Not all tapes are supported by st - OnStream drives need osst instead.
How do you suggest that is to be handled?

> diff -ruNp -x '*~' linux-2.6.11-rc4.hotplug.orig/drivers/scsi/st.c linux-2.6.11-rc4.hotplug/drivers/scsi/st.c
> --- linux-2.6.11-rc4.hotplug.orig/drivers/scsi/st.c	2005-02-13 06:06:55.000000000 +0300
> +++ linux-2.6.11-rc4.hotplug/drivers/scsi/st.c	2005-02-16 04:26:28.000000000 +0300
> @@ -4090,6 +4090,8 @@ static void __exit exit_st(void)
>  	printk(KERN_INFO "st: Unloaded.\n");
>  }
>  
> +MODULE_ALIAS("scsi-type-1");	/*	TYPE_TAPE	*/


Thanks, Willem Riede,
osst maintainer.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Wed, Feb 16, 2005 at 11:02:41PM +0000, Willem Riede wrote:
> On 02/16/2005 06:07:52 AM, Roman Kagan wrote:
> > It handles only st, sd_mod and sr_mod cases (as
> > hotplug-ng-001/module_scsi.c did).  Are there any other?
> 
> Not all tapes are supported by st - OnStream drives need osst instead.

As an excuse I can say that I reproduced what was in
hotplug-ng-001/module_scsi.c, no more, no less :)

> How do you suggest that is to be handled?

AFAICS they coexist nicely, so, if you add the same thing to osst.c:

MODULE_ALIAS("scsi-type-1");	/*	TYPE_TAPE	*/

both osst and st will be loaded (provided Greg convinces Rusty to make
modprobe load _all_ matching modules as he suggested the other day).
Then the one whose .probe succeeds will handle the device.

Will that work?

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Willem Riede]

On 02/16/2005 06:17:41 PM, Roman Kagan wrote:
> On Wed, Feb 16, 2005 at 11:02:41PM +0000, Willem Riede wrote:
> > On 02/16/2005 06:07:52 AM, Roman Kagan wrote:
> > > It handles only st, sd_mod and sr_mod cases (as
> > > hotplug-ng-001/module_scsi.c did).  Are there any other?
> > 
> > Not all tapes are supported by st - OnStream drives need osst instead.
> 
> As an excuse I can say that I reproduced what was in
> hotplug-ng-001/module_scsi.c, no more, no less :)
> 
> > How do you suggest that is to be handled?
> 
> AFAICS they coexist nicely, so, if you add the same thing to osst.c:
> 
> MODULE_ALIAS("scsi-type-1");	/*	TYPE_TAPE	*/
> 
> both osst and st will be loaded (provided Greg convinces Rusty to make
> modprobe load _all_ matching modules as he suggested the other day).
> Then the one whose .probe succeeds will handle the device.
> 
> Will that work?

Yes. If we can get that load-all behaviour implemented, everything will be fine.

Thanks, Willem Riede.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Michael Tokarev]

> On Fri, Feb 11, 2005 at 11:46:27PM +0300, Roman Kagan wrote:
> > On Fri, Feb 11, 2005 at 11:36:27AM -0800, Greg KH wrote:
> > > Do one thing, and do it well.
> > > 
> > > udev is for naming devices, not loading modules.
> > 
> > Well currently udev is doing a lot more: serializing, waiting for sysfs
> > dir to appear, etc.  Not that I disagree with your first statement,
> > though.
> > 
> > > Why, each type of autoload program needs to know how to handle the
> > > different bus types.  So again, a single program doing a single thing
> > > well.
> > 
> > udev already pokes enough in sysfs and has quite a lot of
> > subsystem-specific knowledge, so adding module name generation is not
> > too much of extra functionality.
> 
> If you look at the hotplug scripts, they really don't need to touch
> sysfs at all.  (Note that the scsi one does, but I think we can fix the
> scsi hotplug event to solve this issue...)
> 
> So module autoload has really nothing to do with sysfs.

I tend to disagree, with two points.

1.  Well yes, module autoloading may be done without sysfs just fine
 (but see below).  Yet, module autoloading isn't the only "usage" of
 hotplug subsystem, right?  Ie, in 99.9% of times when a hotplug
 event is emitted, there will be other scripts executed to handle
 the event, and that scripts will depend on sysfs information.

2. And even for module autoloading, $DEVPATH/driver symlink is very-very
 handy, as it's the only (and good) way to check whenever we really want
 to mess with all the module stuff for this device at all: if the symlink
 is present, just do nothing.  Modprobe - if we're moving this functionality
 into modprobe which seems to be a good idea - while loading matching modules
 one by one, can check $DEVPATH/driver to see whenever it should stop walking
 the list.

/mjt


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Thu, Feb 17, 2005 at 09:46:15AM +0300, Michael Tokarev wrote:
> 1.  Well yes, module autoloading may be done without sysfs just fine
>  (but see below).  Yet, module autoloading isn't the only "usage" of
>  hotplug subsystem, right?  Ie, in 99.9% of times when a hotplug
>  event is emitted, there will be other scripts executed to handle
>  the event, and that scripts will depend on sysfs information.

If they do, they'll have to dig in sysfs themselves.  Otherwise how
would the multiplexer communicate the sysfs information to the scripts?

> 2. And even for module autoloading, $DEVPATH/driver symlink is very-very
>  handy, as it's the only (and good) way to check whenever we really want
>  to mess with all the module stuff for this device at all: if the symlink
>  is present, just do nothing.

No, it won't work: until the driver is bound to the device (which likely
happens well after the hotplug event) there's no driver symlink.  Anyway
it's not modprobe's business to check whether the module it loads binds
to the device, it should only check if the requested module is already
loaded, and it has other means to do this.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[jlnance]

On Mon, Feb 14, 2005 at 08:17:25PM -0500, Lee Revell wrote:

> from user space to presenting a login prompt that's way too long.  My
> distro (Debian) runs all the init scripts one at a time, and GDM is the
> last thing that gets run.  There is just no reason for this.  We should
> start X and initialize the display and get the login prompt up there
> ASAP, and let the system acquire the DHCP lease and start sendmail and
> apache and get the date from the NTP server *in the background while I
> am logging in*.  It's not rocket science.

This is debatable.  Windows does something like this.  It really annoys
me that I will get a windows desktop very quickly after logging in
but that I can't do anything with it until some mystrey initialization
takes place.  I would hate to be able to log into my linux machine but
not be able to check email for the first 15 seconds.

Jim


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Chris Larson]

* jlnance@unity.ncsu.edu (jlnance@unity.ncsu.edu) wrote:
> On Mon, Feb 14, 2005 at 08:17:25PM -0500, Lee Revell wrote:
> 
> > from user space to presenting a login prompt that's way too long.  My
> > distro (Debian) runs all the init scripts one at a time, and GDM is the
> > last thing that gets run.  There is just no reason for this.  We should
> > start X and initialize the display and get the login prompt up there
> > ASAP, and let the system acquire the DHCP lease and start sendmail and
> > apache and get the date from the NTP server *in the background while I
> > am logging in*.  It's not rocket science.
> 
> This is debatable.  Windows does something like this.  It really annoys
> me that I will get a windows desktop very quickly after logging in
> but that I can't do anything with it until some mystrey initialization
> takes place.  I would hate to be able to log into my linux machine but
> not be able to check email for the first 15 seconds.

Wouldn't it be sufficient to have an applet in your UI (or dialog,
depending on your preference), which communicates with init and displays
the final initialization steps?  Don't check your email until it says it has
started the services for email.
--
Chris Larson - kergoth at handhelds dot org
Linux Software Systems Engineer - clarson at ti dot com
Core Developer/Architect - BitBake, OpenEmbedded, OpenZaurus


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Helge Hafting]

On Thu, Feb 17, 2005 at 01:37:09PM -0500, jlnance@unity.ncsu.edu wrote:
> On Mon, Feb 14, 2005 at 08:17:25PM -0500, Lee Revell wrote:
> 
> This is debatable.  Windows does something like this.  It really annoys
> me that I will get a windows desktop very quickly after logging in
> but that I can't do anything with it until some mystrey initialization
> takes place.  I would hate to be able to log into my linux machine but
> not be able to check email for the first 15 seconds.

Well, this will depend on your email server (pop? imap? other?)
being up.  Is it local on your machine, or external?  Either way,
being able to launch an email client (or some "new mail" notification
app) shouldn't be a problem.  It will simply not notice new mail until
the mail service comes up - but it won't fail.  It'll be as if the
mail arrived a little later.

Helge Hafting


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Patrick Mansfield]

[added linux-scsi]

On Wed, Feb 16, 2005 at 11:32:51PM +0000, Willem Riede wrote:
> On 02/16/2005 06:17:41 PM, Roman Kagan wrote:

I tried out Roman's patch, well at least simple loading of st via
"modprobe scsi-type-1", works nicely as expected. (modprobe -r sd is
hanging on down() in device_unregister with 2.6.11-rc4 ... must be a ref
count problem, have not figured anything out, and took me a while before
trying st and sg instead.)

> > On Wed, Feb 16, 2005 at 11:02:41PM +0000, Willem Riede wrote:
> > > On 02/16/2005 06:07:52 AM, Roman Kagan wrote:
> > > > It handles only st, sd_mod and sr_mod cases (as
> > > > hotplug-ng-001/module_scsi.c did).  Are there any other?
> > > 
> > > Not all tapes are supported by st - OnStream drives need osst instead.
> > 
> > As an excuse I can say that I reproduced what was in
> > hotplug-ng-001/module_scsi.c, no more, no less :)
> > 
> > > How do you suggest that is to be handled?
> > 
> > AFAICS they coexist nicely, so, if you add the same thing to osst.c:
> > 
> > MODULE_ALIAS("scsi-type-1");	/*	TYPE_TAPE	*/
> > 
> > both osst and st will be loaded (provided Greg convinces Rusty to make
> > modprobe load _all_ matching modules as he suggested the other day).
> > Then the one whose .probe succeeds will handle the device.
> > 
> > Will that work?
> 
> Yes. If we can get that load-all behaviour implemented, everything will be fine.

You could also append the sdev->vendor and sdev->model, and use alias wild
cards.

So OSST would not be loaded for all tape devices found (not a big deal).
st would still load for all tapes (likely the same as we have today, and
not easy to *not* load it for osst devices).

That is, add aliases to osst.c like:

MODULE_ALIAS("scsi-type-1-onStream-SC-*");
MODULE_ALIAS("scsi-type-1-onStream-DI-*");

etc.

The vendor (8 bytes) and model (16 bytes) can have spaces, and the values
are not '\0' terminated. modprobe does not seem to handle spaces in an
alias.

And for st.c:

MODULE_ALIAS("scsi-type-1-*");

sd.c:

MODULE_ALIAS("scsi-type-4-*");
MODULE_ALIAS("scsi-type-5-*");

Also, sg loading would want (along with modprobe load all feature):

MODULE_ALIAS("scsi-type-*");

-- Patrick Mansfield


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 18, 2005 at 09:17:37AM -0800, Patrick Mansfield wrote:
> You could also append the sdev->vendor and sdev->model, and use alias wild
> cards.

String values haven't been used in the aliases so far, and I think for a
reason: with all the unpredictable weird characters and string lengths
they would make maintainance harder, not easier.

> That is, add aliases to osst.c like:
> 
> MODULE_ALIAS("scsi-type-1-onStream-SC-*");
> MODULE_ALIAS("scsi-type-1-onStream-DI-*");

I used dashes for the only reason of these aliases being static.  If
they are supposed to grow it may make sense to stick to the convention
used everywhere else, i.e. bus:devspec.

> Also, sg loading would want (along with modprobe load all feature):
> 
> MODULE_ALIAS("scsi-type-*");

Is it certain that it can live together with s[dtr]?  I thought these
guys now handled all the ioctls sg was supposed to themselves...

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Patrick Mansfield]

On Fri, Feb 18, 2005 at 09:11:06PM +0300, Roman Kagan wrote:
> On Fri, Feb 18, 2005 at 09:17:37AM -0800, Patrick Mansfield wrote:
> > You could also append the sdev->vendor and sdev->model, and use alias wild
> > cards.
> 
> String values haven't been used in the aliases so far, and I think for a
> reason: with all the unpredictable weird characters and string lengths
> they would make maintainance harder, not easier.

Yes, but modprobe should just work with them, even if scripts or other
usage has problems. I haven't seen any really odd strings for vendor or
model, ususally just spaces and alphanumeric, I don't remember (or even
remember where to look) for the allowed characters; there are always
devices that behave badly.

> > Also, sg loading would want (along with modprobe load all feature):
> > 
> > MODULE_ALIAS("scsi-type-*");
> 
> Is it certain that it can live together with s[dtr]?  I thought these
> guys now handled all the ioctls sg was supposed to themselves...

Yes.

The block SG_IO handles the ioctls, but not devices without a SCSI upper
level driver (i.e. not tape, disk or cdrom).

For example, media changers (though a driver has just been submitted),
scanners, enclosure devices, or printers (I've never seen any scsi
printers).

In my experience, there are always applications that want to use the
standard device driver (/dev/sda etc.) and others that want to use a
generic driver.

-- Patrick Mansfield


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 18, 2005 at 10:33:50AM -0800, Patrick Mansfield wrote:
> The block SG_IO handles the ioctls, but not devices without a SCSI upper
> level driver (i.e. not tape, disk or cdrom).

Then it might make sense to explicitly list in sg.c the TYPE_* not
matched by s[dtr].

> In my experience, there are always applications that want to use the
> standard device driver (/dev/sda etc.) and others that want to use a
> generic driver.

So these drivers can compete for the same device?  Are there
deterministic rules on which one is supposed to win?  And is there a
userspace interface to unbind one driver and bind another?  Otherwise it
may mean that automatic module loading is inappropriate here at all...

Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Patrick Mansfield]

On Fri, Feb 18, 2005 at 10:41:35PM +0300, Roman Kagan wrote:
> On Fri, Feb 18, 2005 at 10:33:50AM -0800, Patrick Mansfield wrote:
> > The block SG_IO handles the ioctls, but not devices without a SCSI upper
> > level driver (i.e. not tape, disk or cdrom).
> 
> Then it might make sense to explicitly list in sg.c the TYPE_* not
> matched by s[dtr].

sg can be used even if another scsi upper level driver is loaded.

fedora core tried something like that for a while, I'm not sure what
happened (besides it being really hard to do), and haven't noticed
anything different in recent (2.6.x) fc kernels.

> So these drivers can compete for the same device?  Are there
> deterministic rules on which one is supposed to win?  And is there a
> userspace interface to unbind one driver and bind another?  Otherwise it
> may mean that automatic module loading is inappropriate here at all...

No to all.

It is OK to autoload sg, it has special handling. Even though greg
probably hates it, it is much better than a /proc/bus/scsi ;-)

-- Patrick Mansfield


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Jim Crilly]

> 
> Wouldn't it be sufficient to have an applet in your UI (or dialog,
> depending on your preference), which communicates with init and displays
> the final initialization steps?  Don't check your email until it says it has
> started the services for email.

So now instead of watching the boot messages or bootsplash you want to watch 
an icon on the task bar? In both cases you're just sitting and waiting on 
things to start, so why is waiting in one place better than another?

> --
> Chris Larson - kergoth at handhelds dot org
> Linux Software Systems Engineer - clarson at ti dot com
> Core Developer/Architect - BitBake, OpenEmbedded, OpenZaurus

Jim.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Jim Crilly]

Helge Hafting wrote:
> 
> 
> Well, this will depend on your email server (pop? imap? other?)
> being up.  Is it local on your machine, or external?  Either way,
> being able to launch an email client (or some "new mail" notification
> app) shouldn't be a problem.  It will simply not notice new mail until
> the mail service comes up - but it won't fail.  It'll be as if the
> mail arrived a little later.

Sure it can fail, when you start it up it'll most likely fail to login to 
the mail server, whether it's local or not, if certain services aren't 
already started. If you're using local direct access via maildir or mbox, 
that'll work fine but most people access remote server for their mail.

> 
> Helge Hafting

Jim.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Helge Hafting]

On Sat, Feb 19, 2005 at 12:56:25AM -0500, Jim Crilly wrote:
> Helge Hafting wrote:
> >
> >
> >Well, this will depend on your email server (pop? imap? other?)
> >being up.  Is it local on your machine, or external?  Either way,
> >being able to launch an email client (or some "new mail" notification
> >app) shouldn't be a problem.  It will simply not notice new mail until
> >the mail service comes up - but it won't fail.  It'll be as if the
> >mail arrived a little later.
> 
> Sure it can fail, when you start it up it'll most likely fail to login to 
> the mail server, whether it's local or not, if certain services aren't 
> already started. If you're using local direct access via maildir or mbox, 
> that'll work fine but most people access remote server for their mail.
> 
No problem with the remote server, it does not depend on the local boot process.
The mail program connects directly to the remote server, all you need is the
network and it comes up so fast, it will come up way before X in a parallel boot.

Helge Hafting


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001

[Jim Crilly]

Helge Hafting wrote:
> No problem with the remote server, it does not depend on the local boot process.
> The mail program connects directly to the remote server, all you need is the
> network and it comes up so fast, it will come up way before X in a parallel boot.

Depends on the implementation and what's required for network connectivity 
to the remote server. When I said that I was talking about the method that 
Lee Revell talked about, where he said "We should start X and initialize the 
display and get the login prompt up there ASAP, and let the system acquire 
the DHCP lease and start sendmail and apache and get the date from the NTP 
server *in the background while I am logging in*.  It's not rocket science". 
Obviously, if the network is started synchronously it won't matter.

> Helge Hafting

Jim.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Erik van Konijnenburg]

On Sat, Feb 12, 2005 at 03:34:58AM +0300, Roman Kagan wrote:
> Then why not just make the kernel (and coldplug) create an additional
> environment variable with the fnmatch-able module name ready to use with
> modprobe?  Given that kernel (and coldplug) have all the IDs in the nice
> integer form it would be a matter of a single add_hotplug_env_var() (or
> sprintf()) call per each device type, and would be even tinier that the
> hotplug-ng :)

There's one twist that I can't figure out:

Here's the matching code from usb.c, which is emulated by
hotplug/usb.agent:
	if ((id->match_flags & USB_DEVICE_ID_MATCH_DEV_LO) &&
	    (id->bcdDevice_lo > dev->descriptor.bcdDevice))
		continue;

	if ((id->match_flags & USB_DEVICE_ID_MATCH_DEV_HI) &&
	    (id->bcdDevice_hi < dev->descriptor.bcdDevice))
		continue;

Here are some samples from modules.alias:
	alias usb:v097Ap0001dl0000dh0001dc*dsc*dp*ic*isc*ip* usb_storage
	alias usb:v05A9p0511dl*dh*dc*dsc*dp*ic*isc*ip* ov511

And the read_config_file function in modprobe.c simply does a shell
style wildcard match.

How can wildcard matching in modprobe against these aliases give the same
result as a numeric range comparison on DEV_LO and DEV_HI in kernel and
hotplug agents?

Since I don't know what modules.aliases was originally intended for,
I may be missing something obvious.  Any hints appreciated.

Regards,
Erik




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Mon, Feb 21, 2005 at 09:40:04PM +0100, Erik van Konijnenburg wrote:
> Here are some samples from modules.alias:
> 	alias usb:v097Ap0001dl0000dh0001dc*dsc*dp*ic*isc*ip* usb_storage
> 	alias usb:v05A9p0511dl*dh*dc*dsc*dp*ic*isc*ip* ov511
> 
> And the read_config_file function in modprobe.c simply does a shell
> style wildcard match.
> 
> How can wildcard matching in modprobe against these aliases give the same
> result as a numeric range comparison on DEV_LO and DEV_HI in kernel and
> hotplug agents?
> 
> Since I don't know what modules.aliases was originally intended for,
> I may be missing something obvious.  Any hints appreciated.

That wasn't you who missed something obvious :)  Actually this problem
existed since day 0 and presumably was due to the fact that USB was (and
still is) the only kind which used numeric ranges and thus had two
parameters to match a single value against, which was probably
overlooked when scripts/mod/file2alias.c was written.

The only solution I could come up with was to modify that file to
generate multiple patterns (and thus MODULE_ALIAS strings) out of a
usb_match_id which defined a range of bcdDevice values, e.g. given a
range between 0x0001 and 0xa345 it would create 7 patterns:

000[1-F]*
00[1-F]*
0[1-F]*
[1-9]*
A[0-2]*
A3[0-3]*
A34[0-5]*

Since bcdDevice is 2 bytes wide = 4 digits in hex representation, the
max no. of patters is 2 * 4 - 1 = 7.

The attached patch does this.  Please comment and consider applying.

Thanks,
  Roman.


--- linux-2.6.11-rc4/scripts/mod/file2alias.c.orig	2005-02-13 10:06:23.000000000 +0300
+++ linux-2.6.11-rc4/scripts/mod/file2alias.c	2005-02-22 12:58:05.849081056 +0300
@@ -47,32 +47,19 @@
                 sprintf(str + strlen(str), "*");                \
 } while(0)
 
-/* Looks like "usb:vNpNdlNdhNdcNdscNdpNicNiscNipN" */
-static int do_usb_entry(const char *filename,
-			struct usb_device_id *id, char *alias)
+/* USB is special because the bcdDevice can be matched against a numeric range */
+/* Looks like "usb:vNpNdNdcNdscNdpNicNiscNipN" */
+static void do_usb_entry(struct usb_device_id *id, const char *bcdDevice_pattern,
+			 struct module *mod)
 {
-	id->match_flags = TO_NATIVE(id->match_flags);
-	id->idVendor = TO_NATIVE(id->idVendor);
-	id->idProduct = TO_NATIVE(id->idProduct);
-	id->bcdDevice_lo = TO_NATIVE(id->bcdDevice_lo);
-	id->bcdDevice_hi = TO_NATIVE(id->bcdDevice_hi);
-
-	/*
-	 * Some modules (visor) have empty slots as placeholder for
-	 * run-time specification that results in catch-all alias
-	 */
-	if (!(id->idVendor | id->bDeviceClass | id->bInterfaceClass))
-		return 1;
-
+	char alias[500];
 	strcpy(alias, "usb:");
 	ADD(alias, "v", id->match_flags&USB_DEVICE_ID_MATCH_VENDOR,
 	    id->idVendor);
 	ADD(alias, "p", id->match_flags&USB_DEVICE_ID_MATCH_PRODUCT,
 	    id->idProduct);
-	ADD(alias, "dl", id->match_flags&USB_DEVICE_ID_MATCH_DEV_LO,
-	    id->bcdDevice_lo);
-	ADD(alias, "dh", id->match_flags&USB_DEVICE_ID_MATCH_DEV_HI,
-	    id->bcdDevice_hi);
+	strcat(alias, "d");
+	strcat(alias, bcdDevice_pattern);
 	ADD(alias, "dc", id->match_flags&USB_DEVICE_ID_MATCH_DEV_CLASS,
 	    id->bDeviceClass);
 	ADD(alias, "dsc",
@@ -90,7 +77,104 @@
 	ADD(alias, "ip",
 	    id->match_flags&USB_DEVICE_ID_MATCH_INT_PROTOCOL,
 	    id->bInterfaceProtocol);
-	return 1;
+
+	/* Always end in a wildcard, for future extension */
+	if (alias[strlen(alias)-1] != '*')
+		strcat(alias, "*");
+	buf_printf(&mod->dev_table_buf,
+		   "MODULE_ALIAS(\"%s\");\n", alias);
+}
+
+
+static inline size_t sprint_pattern(char *str, int ndigits, unsigned int initial,
+				  unsigned char clo, unsigned char chi)
+{
+	if (ndigits) {
+		if (clo = chi)
+			return sprintf(str, "%0*X%X*", ndigits, initial, clo);
+		if (clo = 0x0 && chi = 0xf)
+			return sprintf(str, "%0*X*", ndigits, initial);
+		return sprintf(str, "%0*X[%X-%X]*", ndigits, initial, clo, chi);
+	}
+	else {
+		if (clo = chi)
+			return sprintf(str, "%X*", clo);
+		if (clo = 0x0 && chi = 0xf)
+			return sprintf(str, "*");
+		return sprintf(str, "[%X-%X]*", clo, chi);
+	}
+}
+
+static void do_usb_entry_multi(struct usb_device_id *id, struct module *mod)
+{
+	unsigned int devlo, devhi;
+	unsigned char chi, clo;
+	int ndigits;
+	char pattern[32];
+
+	id->match_flags = TO_NATIVE(id->match_flags);
+	id->idVendor = TO_NATIVE(id->idVendor);
+	id->idProduct = TO_NATIVE(id->idProduct);
+
+	devlo = id->match_flags & USB_DEVICE_ID_MATCH_DEV_LO ?
+		TO_NATIVE(id->bcdDevice_lo) : 0x0U;
+	devhi = id->match_flags & USB_DEVICE_ID_MATCH_DEV_HI ?
+		TO_NATIVE(id->bcdDevice_hi) : ~0x0U;
+
+	/*
+	 * Some modules (visor) have empty slots as placeholder for
+	 * run-time specification that results in catch-all alias
+	 */
+	if (!(id->idVendor | id->bDeviceClass | id->bInterfaceClass))
+		return;
+
+	/* Convert numeric bcdDevice range into fnmatch-able pattern(s) */
+	for (ndigits = sizeof(id->bcdDevice_lo) * 2 - 1; 1; ndigits--) {
+		clo = devlo & 0xf;
+		chi = devhi & 0xf;
+		devlo >>= 4;
+		devhi >>= 4;
+
+		if (devlo = devhi || !ndigits) {
+			if (clo <= chi) {
+				sprint_pattern(pattern, ndigits, devlo, clo, chi);
+				do_usb_entry(id, pattern, mod);
+				printf("%s\n", pattern);
+			}
+			break;
+		}
+
+		if (clo != 0x0) {
+			sprint_pattern(pattern, ndigits, devlo, clo, 0xf);
+			do_usb_entry(id, pattern, mod);
+			printf("%s\n", pattern);
+			devlo++;
+		}
+
+		if (chi != 0xf) {
+			sprint_pattern(pattern, ndigits, devhi, 0x0, chi);
+			do_usb_entry(id, pattern, mod);
+			printf("%s\n", pattern);
+			devhi--;
+		}
+	}
+}
+
+static void do_usb_table(void *symval, unsigned long size,
+			 struct module *mod)
+{
+	unsigned int i;
+	const unsigned long id_size = sizeof(struct usb_device_id);
+
+	if (size % id_size || size < id_size) {
+		fprintf(stderr, "*** Warning: %s ids %lu bad size "
+			"(each on %lu)\n", mod->name, size, id_size);
+	}
+	/* Leave last one: it's the terminator. */
+	size -= id_size;
+
+	for (i = 0; i < size; i += id_size)
+		do_usb_entry_multi(symval + i, mod);
 }
 
 /* Looks like: ieee1394:venNmoNspNverN */
@@ -262,8 +346,8 @@
 		do_table(symval, sym->st_size, sizeof(struct pci_device_id),
 			 do_pci_entry, mod);
 	else if (sym_is(symname, "__mod_usb_device_table"))
-		do_table(symval, sym->st_size, sizeof(struct usb_device_id),
-			 do_usb_entry, mod);
+		/* special case to handle bcdDevice ranges */
+		do_usb_table(symval, sym->st_size, mod);
 	else if (sym_is(symname, "__mod_ieee1394_device_table"))
 		do_table(symval, sym->st_size, sizeof(struct ieee1394_device_id),
 			 do_ieee1394_entry, mod);


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Erik van Konijnenburg]

Some notes in the patch.

On Tue, Feb 22, 2005 at 01:35:03PM +0300, Roman Kagan wrote:
> On Mon, Feb 21, 2005 at 09:40:04PM +0100, Erik van Konijnenburg wrote:
> > Here are some samples from modules.alias:
> > 	alias usb:v097Ap0001dl0000dh0001dc*dsc*dp*ic*isc*ip* usb_storage
> > 	alias usb:v05A9p0511dl*dh*dc*dsc*dp*ic*isc*ip* ov511
> > 
> > And the read_config_file function in modprobe.c simply does a shell
> > style wildcard match.
> > 
> > How can wildcard matching in modprobe against these aliases give the same
> > result as a numeric range comparison on DEV_LO and DEV_HI in kernel and
> > hotplug agents?
> > 
> > Since I don't know what modules.aliases was originally intended for,
> > I may be missing something obvious.  Any hints appreciated.
> 
> That wasn't you who missed something obvious :)  Actually this problem
> existed since day 0 and presumably was due to the fact that USB was (and
> still is) the only kind which used numeric ranges and thus had two
> parameters to match a single value against, which was probably
> overlooked when scripts/mod/file2alias.c was written.
> 
> The only solution I could come up with was to modify that file to
> generate multiple patterns (and thus MODULE_ALIAS strings) out of a
> usb_match_id which defined a range of bcdDevice values, e.g. given a
> range between 0x0001 and 0xa345 it would create 7 patterns:
> 
> 000[1-F]*
> 00[1-F]*
> 0[1-F]*
> [1-9]*
> A[0-2]*
> A3[0-3]*
> A34[0-5]*
> 
> Since bcdDevice is 2 bytes wide = 4 digits in hex representation, the
> max no. of patters is 2 * 4 - 1 = 7.

Nice!  Far fewer patterns needed than I feared.

> 
> The attached patch does this.  Please comment and consider applying.
> 
> Thanks,
>   Roman.
> 
> 
> --- linux-2.6.11-rc4/scripts/mod/file2alias.c.orig	2005-02-13 10:06:23.000000000 +0300
> +++ linux-2.6.11-rc4/scripts/mod/file2alias.c	2005-02-22 12:58:05.849081056 +0300
> @@ -47,32 +47,19 @@
>                  sprintf(str + strlen(str), "*");                \
>  } while(0)
>  
> -/* Looks like "usb:vNpNdlNdhNdcNdscNdpNicNiscNipN" */
> -static int do_usb_entry(const char *filename,
> -			struct usb_device_id *id, char *alias)
> +/* USB is special because the bcdDevice can be matched against a numeric range */
> +/* Looks like "usb:vNpNdNdcNdscNdpNicNiscNipN" */

Hmm.  A change in the alias pattern: dl*dh* => d*, but given the meaning of
the pattern it's probably the right thing.  Who generates stuff
that needs to be matched against this?

> +static void do_usb_entry(struct usb_device_id *id, const char *bcdDevice_pattern,
> +			 struct module *mod)
>  {
> -	id->match_flags = TO_NATIVE(id->match_flags);
> -	id->idVendor = TO_NATIVE(id->idVendor);
> -	id->idProduct = TO_NATIVE(id->idProduct);
> -	id->bcdDevice_lo = TO_NATIVE(id->bcdDevice_lo);
> -	id->bcdDevice_hi = TO_NATIVE(id->bcdDevice_hi);
> -
> -	/*
> -	 * Some modules (visor) have empty slots as placeholder for
> -	 * run-time specification that results in catch-all alias
> -	 */
> -	if (!(id->idVendor | id->bDeviceClass | id->bInterfaceClass))
> -		return 1;
> -
> +	char alias[500];
>  	strcpy(alias, "usb:");
>  	ADD(alias, "v", id->match_flags&USB_DEVICE_ID_MATCH_VENDOR,
>  	    id->idVendor);
>  	ADD(alias, "p", id->match_flags&USB_DEVICE_ID_MATCH_PRODUCT,
>  	    id->idProduct);
> -	ADD(alias, "dl", id->match_flags&USB_DEVICE_ID_MATCH_DEV_LO,
> -	    id->bcdDevice_lo);
> -	ADD(alias, "dh", id->match_flags&USB_DEVICE_ID_MATCH_DEV_HI,
> -	    id->bcdDevice_hi);
> +	strcat(alias, "d");
> +	strcat(alias, bcdDevice_pattern);
>  	ADD(alias, "dc", id->match_flags&USB_DEVICE_ID_MATCH_DEV_CLASS,
>  	    id->bDeviceClass);
>  	ADD(alias, "dsc",
> @@ -90,7 +77,104 @@
>  	ADD(alias, "ip",
>  	    id->match_flags&USB_DEVICE_ID_MATCH_INT_PROTOCOL,
>  	    id->bInterfaceProtocol);
> -	return 1;
> +
> +	/* Always end in a wildcard, for future extension */
> +	if (alias[strlen(alias)-1] != '*')
> +		strcat(alias, "*");
> +	buf_printf(&mod->dev_table_buf,
> +		   "MODULE_ALIAS(\"%s\");\n", alias);
> +}
> +
> +
> +static inline size_t sprint_pattern(char *str, int ndigits, unsigned int initial,
> +				  unsigned char clo, unsigned char chi)
> +{
> +	if (ndigits) {
> +		if (clo = chi)
> +			return sprintf(str, "%0*X%X*", ndigits, initial, clo);
> +		if (clo = 0x0 && chi = 0xf)
> +			return sprintf(str, "%0*X*", ndigits, initial);
> +		return sprintf(str, "%0*X[%X-%X]*", ndigits, initial, clo, chi);
> +	}
> +	else {
> +		if (clo = chi)
> +			return sprintf(str, "%X*", clo);
> +		if (clo = 0x0 && chi = 0xf)
> +			return sprintf(str, "*");
> +		return sprintf(str, "[%X-%X]*", clo, chi);
> +	}
> +}
> +
> +static void do_usb_entry_multi(struct usb_device_id *id, struct module *mod)
> +{
> +	unsigned int devlo, devhi;
> +	unsigned char chi, clo;
> +	int ndigits;
> +	char pattern[32];
> +
> +	id->match_flags = TO_NATIVE(id->match_flags);
> +	id->idVendor = TO_NATIVE(id->idVendor);
> +	id->idProduct = TO_NATIVE(id->idProduct);
> +
> +	devlo = id->match_flags & USB_DEVICE_ID_MATCH_DEV_LO ?
> +		TO_NATIVE(id->bcdDevice_lo) : 0x0U;
> +	devhi = id->match_flags & USB_DEVICE_ID_MATCH_DEV_HI ?
> +		TO_NATIVE(id->bcdDevice_hi) : ~0x0U;
> +
> +	/*
> +	 * Some modules (visor) have empty slots as placeholder for
> +	 * run-time specification that results in catch-all alias
> +	 */
> +	if (!(id->idVendor | id->bDeviceClass | id->bInterfaceClass))
> +		return;
> +
> +	/* Convert numeric bcdDevice range into fnmatch-able pattern(s) */
> +	for (ndigits = sizeof(id->bcdDevice_lo) * 2 - 1; 1; ndigits--) {

By changing the termination condition to devhi < devlo, we could
avoid ghost matches for ranges such as 6009-4002.  That's a useless but
well-defined range, and some driver author might find it convenient not to
filter such stuff from his array; silenty misinterpreting it seems unkind.

The loop body is tricky; at first sight it looks OK, but I did not do a full
blown analysis with loop invariants.

		/* ndigits is the number of digits that is copied unchanged
		 * from the lo/hi numbers to the pattern in this iteration.
		 */

> +		clo = devlo & 0xf;
> +		chi = devhi & 0xf;
> +		devlo >>= 4;
> +		devhi >>= 4;
> +
> +		if (devlo = devhi || !ndigits) {
> +			if (clo <= chi) {
> +				sprint_pattern(pattern, ndigits, devlo, clo, chi);
> +				do_usb_entry(id, pattern, mod);
> +				printf("%s\n", pattern);
> +			}
> +			break;
> +		}
> +
> +		if (clo != 0x0) {
> +			sprint_pattern(pattern, ndigits, devlo, clo, 0xf);
> +			do_usb_entry(id, pattern, mod);
> +			printf("%s\n", pattern);
> +			devlo++;
> +		}
> +
> +		if (chi != 0xf) {
> +			sprint_pattern(pattern, ndigits, devhi, 0x0, chi);
> +			do_usb_entry(id, pattern, mod);
> +			printf("%s\n", pattern);
> +			devhi--;

Signedness issues?  Consider the range 0001-0002: at start of the loop
body you split in 000 + 1, 000 + 2, here you decrement unsigned devhi
from 0 to 0xfffffff.

> +		}
> +	}
> +}
> +
> +static void do_usb_table(void *symval, unsigned long size,
> +			 struct module *mod)
> +{
> +	unsigned int i;
> +	const unsigned long id_size = sizeof(struct usb_device_id);
> +
> +	if (size % id_size || size < id_size) {
> +		fprintf(stderr, "*** Warning: %s ids %lu bad size "
> +			"(each on %lu)\n", mod->name, size, id_size);
> +	}
> +	/* Leave last one: it's the terminator. */
> +	size -= id_size;
> +
> +	for (i = 0; i < size; i += id_size)
> +		do_usb_entry_multi(symval + i, mod);
>  }
>  
>  /* Looks like: ieee1394:venNmoNspNverN */
> @@ -262,8 +346,8 @@
>  		do_table(symval, sym->st_size, sizeof(struct pci_device_id),
>  			 do_pci_entry, mod);
>  	else if (sym_is(symname, "__mod_usb_device_table"))
> -		do_table(symval, sym->st_size, sizeof(struct usb_device_id),
> -			 do_usb_entry, mod);
> +		/* special case to handle bcdDevice ranges */
> +		do_usb_table(symval, sym->st_size, mod);
>  	else if (sym_is(symname, "__mod_ieee1394_device_table"))
>  		do_table(symval, sym->st_size, sizeof(struct ieee1394_device_id),
>  			 do_ieee1394_entry, mod);

Regards,
Erik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Wed, Feb 23, 2005 at 01:44:04AM +0100, Erik van Konijnenburg wrote:
> > -/* Looks like "usb:vNpNdlNdhNdcNdscNdpNicNiscNipN" */
> > -static int do_usb_entry(const char *filename,
> > -			struct usb_device_id *id, char *alias)
> > +/* USB is special because the bcdDevice can be matched against a numeric range */
> > +/* Looks like "usb:vNpNdNdcNdscNdpNicNiscNipN" */
> 
> Hmm.  A change in the alias pattern: dl*dh* => d*, but given the meaning of
> the pattern it's probably the right thing.  Who generates stuff
> that needs to be matched against this?

One of those who did was my patch I sent a few days ago :)

Whoever it was, there were only few trivial cases which worked: when
either USB_DEVICE_ID_MATCH_DEV_LO or USB_DEVICE_ID_MATCH_DEV_HI were
false, or when bcdDevice_lo = bcdDevice_hi.  Otherwise there's no
sensible way to construct something which would match against two
different numbers simultaneously.

BTW the most common match-everything case dl*dh* will be converted into
d* and thus continue to work.

> > +	/* Convert numeric bcdDevice range into fnmatch-able pattern(s) */
> > +	for (ndigits = sizeof(id->bcdDevice_lo) * 2 - 1; 1; ndigits--) {
> 
> By changing the termination condition to devhi < devlo, we could
> avoid ghost matches for ranges such as 6009-4002.

Ah, valid point, thanks!  I didn't test it.

> The loop body is tricky; at first sight it looks OK, but I did not do a full
> blown analysis with loop invariants.

Yep, the code is somewhat ugly, I'll try to clean it up a bit tonight or
tomorrow and resend.

> > +		if (devlo = devhi || !ndigits) {
> > +			if (clo <= chi) {
> > +				sprint_pattern(pattern, ndigits, devlo, clo, chi);
> > +				do_usb_entry(id, pattern, mod);
> > +				printf("%s\n", pattern);
> > +			}
> > +			break;
> > +		}
> > +
> > +		if (clo != 0x0) {
> > +			sprint_pattern(pattern, ndigits, devlo, clo, 0xf);
> > +			do_usb_entry(id, pattern, mod);
> > +			printf("%s\n", pattern);
> > +			devlo++;
> > +		}
> > +
> > +		if (chi != 0xf) {
> > +			sprint_pattern(pattern, ndigits, devhi, 0x0, chi);
> > +			do_usb_entry(id, pattern, mod);
> > +			printf("%s\n", pattern);
> > +			devhi--;
> 
> Signedness issues?  Consider the range 0001-0002: at start of the loop
> body you split in 000 + 1, 000 + 2, here you decrement unsigned devhi
> from 0 to 0xfffffff.

No, when I reach here I have devlo != devhi, with normal ranges (or with
your proposed check added) this means devlo < devhi, so no
over/underflows are possible.

BTW are alphanumeric ranges like [3-C] guaranteed to work with fnmatch
as expected for hex digits regardless of locale settings?  Otherwise
I'll need to replace them with explicit list of allowed digits, i.e.
[3456789ABC] (not any more difficult but less beautiful).  Anybody here
with a clue?

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Erik van Konijnenburg]

On Wed, Feb 23, 2005 at 02:40:01PM +0300, Roman Kagan wrote:
> On Wed, Feb 23, 2005 at 01:44:04AM +0100, Erik van Konijnenburg wrote:
> > > -/* Looks like "usb:vNpNdlNdhNdcNdscNdpNicNiscNipN" */
> > > -static int do_usb_entry(const char *filename,
> > > -			struct usb_device_id *id, char *alias)
> > > +/* USB is special because the bcdDevice can be matched against a numeric range */
> > > +/* Looks like "usb:vNpNdNdcNdscNdpNicNiscNipN" */
> > 
> > Hmm.  A change in the alias pattern: dl*dh* => d*, but given the meaning of
> > the pattern it's probably the right thing.  Who generates stuff
> > that needs to be matched against this?
> 
> One of those who did was my patch I sent a few days ago :)
> 
> Whoever it was, there were only few trivial cases which worked: when
> either USB_DEVICE_ID_MATCH_DEV_LO or USB_DEVICE_ID_MATCH_DEV_HI were
> false, or when bcdDevice_lo = bcdDevice_hi.  Otherwise there's no
> sensible way to construct something which would match against two
> different numbers simultaneously.
> 
> BTW the most common match-everything case dl*dh* will be converted into
> d* and thus continue to work.

OK, I was worrying about migration issues, but the fact that d* matches
dl*dh* covers that.

> 
> > > +	/* Convert numeric bcdDevice range into fnmatch-able pattern(s) */
> > > +	for (ndigits = sizeof(id->bcdDevice_lo) * 2 - 1; 1; ndigits--) {
> > 
> > By changing the termination condition to devhi < devlo, we could
> > avoid ghost matches for ranges such as 6009-4002.
> 
> Ah, valid point, thanks!  I didn't test it.
> 
> > The loop body is tricky; at first sight it looks OK, but I did not do a full
> > blown analysis with loop invariants.
> 
> Yep, the code is somewhat ugly, I'll try to clean it up a bit tonight or
> tomorrow and resend.
> 
> > > +		if (devlo = devhi || !ndigits) {
> > > +			if (clo <= chi) {
> > > +				sprint_pattern(pattern, ndigits, devlo, clo, chi);
> > > +				do_usb_entry(id, pattern, mod);
> > > +				printf("%s\n", pattern);
> > > +			}
> > > +			break;
> > > +		}
> > > +
> > > +		if (clo != 0x0) {
> > > +			sprint_pattern(pattern, ndigits, devlo, clo, 0xf);
> > > +			do_usb_entry(id, pattern, mod);
> > > +			printf("%s\n", pattern);
> > > +			devlo++;
> > > +		}
> > > +
> > > +		if (chi != 0xf) {
> > > +			sprint_pattern(pattern, ndigits, devhi, 0x0, chi);
> > > +			do_usb_entry(id, pattern, mod);
> > > +			printf("%s\n", pattern);
> > > +			devhi--;
> > 
> > Signedness issues?  Consider the range 0001-0002: at start of the loop
> > body you split in 000 + 1, 000 + 2, here you decrement unsigned devhi
> > from 0 to 0xfffffff.
> 
> No, when I reach here I have devlo != devhi, with normal ranges (or with
> your proposed check added) this means devlo < devhi, so no
> over/underflows are possible.

Oops, you're right.

> BTW are alphanumeric ranges like [3-C] guaranteed to work with fnmatch
> as expected for hex digits regardless of locale settings?  Otherwise
> I'll need to replace them with explicit list of allowed digits, i.e.
> [3456789ABC] (not any more difficult but less beautiful).  Anybody here
> with a clue?

Quoting from glibc-2.3.2.ds1/build-tree/glibc-2.3.2/posix/fnmatch_loop.c:
                        /* We have to handling the symbols differently in
                           ranges since then the collation sequence is
                           important.  */
                        is_range = *p = L('-') && p[1] != L('\0');

That suggests they want locale dictionary order, not hex.
I could not find fnmatch in the klibc distributed with hotplug-ng
or in old udev sources lying around.  A small test program shows some silly
matches:

	konijn@framboos:~/libc/x$ cat t.c; ./t
	main () {
		t ("[0-F]", "1");
		t ("[0-F]", "D");
		t ("[0-9A-F]", "D");
		t ("[A-F]", "D");
		t ("[0-F]", "?");
		t ("[0-F]", "d");
		t ("[0-d]", "F");
		t ("[0-F]", ":");
		t ("[0-9]", ":");
	}

	t (char * pat, char * val) {
		int matches = ! fnmatch (pat, val, 0);
		printf ("match pat=%s, val=%s, matches=%d\n", pat, val, matches);
	}
	match pat=[0-F], val=1, matches=1
	match pat=[0-F], val=D, matches=1
	match pat=[0-9A-F], val=D, matches=1
	match pat=[A-F], val=D, matches=1
	match pat=[0-F], val=?, matches=1
	match pat=[0-F], val=d, matches=0
	match pat=[0-d], val=F, matches=1
	match pat=[0-F], val=:, matches=1
	match pat=[0-9], val=:, matches=0
	konijn@framboos:~/libc/x$

Regards,
Erik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Wed, Feb 23, 2005 at 02:04:47PM +0100, Erik van Konijnenburg wrote:
> That suggests they want locale dictionary order, not hex.

OK, here's a different version which lists explicitly the allowed
charactes in the range, e.g. for a range between 0x0001 0xa345 it gives

000[123456789ABCDEF]*
00[123456789ABCDEF]*
0[123456789ABCDEF]*
[123456789]*
A[012]*
A3[0123]*
A34[012345]*

Also I tried to improve the comprehensibility of the code a bit.
Comments?

Cheers,
  Roman.

--- linux-2.6.11-rc4/scripts/mod/file2alias.c.orig	2005-02-13 06:06:23.000000000 +0300
+++ linux-2.6.11-rc4/scripts/mod/file2alias.c	2005-02-24 09:11:53.945050552 +0300
@@ -47,32 +47,34 @@
                 sprintf(str + strlen(str), "*");                \
 } while(0)
 
-/* Looks like "usb:vNpNdlNdhNdcNdscNdpNicNiscNipN" */
-static int do_usb_entry(const char *filename,
-			struct usb_device_id *id, char *alias)
+/* USB is special because the bcdDevice can be matched against a numeric range */
+/* Looks like "usb:vNpNdNdcNdscNdpNicNiscNipN" */
+static void do_usb_entry(struct usb_device_id *id,
+			 unsigned int bcdDevice_initial, int bcdDevice_initial_digits,
+			 unsigned char range_lo, unsigned char range_hi,
+			 struct module *mod)
 {
-	id->match_flags = TO_NATIVE(id->match_flags);
-	id->idVendor = TO_NATIVE(id->idVendor);
-	id->idProduct = TO_NATIVE(id->idProduct);
-	id->bcdDevice_lo = TO_NATIVE(id->bcdDevice_lo);
-	id->bcdDevice_hi = TO_NATIVE(id->bcdDevice_hi);
-
-	/*
-	 * Some modules (visor) have empty slots as placeholder for
-	 * run-time specification that results in catch-all alias
-	 */
-	if (!(id->idVendor | id->bDeviceClass | id->bInterfaceClass))
-		return 1;
-
+	static const char hexdigits[] = "0123456789ABCDEF";
+	char alias[500];
 	strcpy(alias, "usb:");
 	ADD(alias, "v", id->match_flags&USB_DEVICE_ID_MATCH_VENDOR,
 	    id->idVendor);
 	ADD(alias, "p", id->match_flags&USB_DEVICE_ID_MATCH_PRODUCT,
 	    id->idProduct);
-	ADD(alias, "dl", id->match_flags&USB_DEVICE_ID_MATCH_DEV_LO,
-	    id->bcdDevice_lo);
-	ADD(alias, "dh", id->match_flags&USB_DEVICE_ID_MATCH_DEV_HI,
-	    id->bcdDevice_hi);
+
+	strcat(alias, "d");
+	if (bcdDevice_initial_digits)
+		sprintf(alias + strlen(alias), "%0*X",
+			bcdDevice_initial_digits, bcdDevice_initial);
+	if (range_lo = range_hi)
+		strncat(alias, hexdigits + range_lo, 1);
+	else if (range_lo > 0x0 || range_hi < 0xf) {
+		strcat(alias, "[");
+		strncat(alias, hexdigits + range_lo, range_hi - range_lo + 1);
+		strcat(alias, "]");
+	}
+	strcat(alias, "*");
+
 	ADD(alias, "dc", id->match_flags&USB_DEVICE_ID_MATCH_DEV_CLASS,
 	    id->bDeviceClass);
 	ADD(alias, "dsc",
@@ -90,7 +92,75 @@
 	ADD(alias, "ip",
 	    id->match_flags&USB_DEVICE_ID_MATCH_INT_PROTOCOL,
 	    id->bInterfaceProtocol);
-	return 1;
+
+	/* Always end in a wildcard, for future extension */
+	if (alias[strlen(alias)-1] != '*')
+		strcat(alias, "*");
+	buf_printf(&mod->dev_table_buf,
+		   "MODULE_ALIAS(\"%s\");\n", alias);
+}
+
+static void do_usb_entry_multi(struct usb_device_id *id, struct module *mod)
+{
+	unsigned int devlo, devhi;
+	unsigned char chi, clo;
+	int ndigits;
+
+	id->match_flags = TO_NATIVE(id->match_flags);
+	id->idVendor = TO_NATIVE(id->idVendor);
+	id->idProduct = TO_NATIVE(id->idProduct);
+
+	devlo = id->match_flags & USB_DEVICE_ID_MATCH_DEV_LO ?
+		TO_NATIVE(id->bcdDevice_lo) : 0x0U;
+	devhi = id->match_flags & USB_DEVICE_ID_MATCH_DEV_HI ?
+		TO_NATIVE(id->bcdDevice_hi) : ~0x0U;
+
+	/*
+	 * Some modules (visor) have empty slots as placeholder for
+	 * run-time specification that results in catch-all alias
+	 */
+	if (!(id->idVendor | id->bDeviceClass | id->bInterfaceClass))
+		return;
+
+	/* Convert numeric bcdDevice range into fnmatch-able pattern(s) */
+	for (ndigits = sizeof(id->bcdDevice_lo) * 2 - 1; devlo <= devhi; ndigits--) {
+		clo = devlo & 0xf;
+		chi = devhi & 0xf;
+		devlo >>= 4;
+		devhi >>= 4;
+
+		if (devlo = devhi || !ndigits) {
+			do_usb_entry(id, devlo, ndigits, clo, chi, mod);
+			break;
+		}
+
+		if (clo != 0x0) {
+			do_usb_entry(id, devlo, ndigits, clo, 0xf, mod);
+			devlo++;
+		}
+
+		if (chi != 0xf) {
+			do_usb_entry(id, devhi, ndigits, 0x0, chi, mod);
+			devhi--;
+		}
+	}
+}
+
+static void do_usb_table(void *symval, unsigned long size,
+			 struct module *mod)
+{
+	unsigned int i;
+	const unsigned long id_size = sizeof(struct usb_device_id);
+
+	if (size % id_size || size < id_size) {
+		fprintf(stderr, "*** Warning: %s ids %lu bad size "
+			"(each on %lu)\n", mod->name, size, id_size);
+	}
+	/* Leave last one: it's the terminator. */
+	size -= id_size;
+
+	for (i = 0; i < size; i += id_size)
+		do_usb_entry_multi(symval + i, mod);
 }
 
 /* Looks like: ieee1394:venNmoNspNverN */
@@ -262,8 +332,8 @@
 		do_table(symval, sym->st_size, sizeof(struct pci_device_id),
 			 do_pci_entry, mod);
 	else if (sym_is(symname, "__mod_usb_device_table"))
-		do_table(symval, sym->st_size, sizeof(struct usb_device_id),
-			 do_usb_entry, mod);
+		/* special case to handle bcdDevice ranges */
+		do_usb_table(symval, sym->st_size, mod);
 	else if (sym_is(symname, "__mod_ieee1394_device_table"))
 		do_table(symval, sym->st_size, sizeof(struct ieee1394_device_id),
 			 do_ieee1394_entry, mod);


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Erik van Konijnenburg]

On Thu, Feb 24, 2005 at 09:27:11AM +0300, Roman Kagan wrote:
> On Wed, Feb 23, 2005 at 02:04:47PM +0100, Erik van Konijnenburg wrote:
> > That suggests they want locale dictionary order, not hex.
> 
> OK, here's a different version which lists explicitly the allowed
> charactes in the range, e.g. for a range between 0x0001 0xa345 it gives
> 
> 000[123456789ABCDEF]*
> 00[123456789ABCDEF]*
> 0[123456789ABCDEF]*
> [123456789]*
> A[012]*
> A3[0123]*
> A34[012345]*
> 
> Also I tried to improve the comprehensibility of the code a bit.
> Comments?

Looks fine to me.

Thanks,
Erik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Wed, Feb 16, 2005 at 02:07:52PM +0300, Roman Kagan wrote:
> Below is the promised patch dealing with scsi module loading (can't
> compile-test it at the moment, sorry).  It has two caveats (I suspect
> you'll find more :) :
> 
>  1) I'm not particularly certain about the "scsi-type-" prefix: it may
>     resemble cases where request_module() is used;
> 
>  2) TYPE_* macros in include/linux/scsi.h are in hex and can't be
>     conveniently __stringify()-ed, so I've hardcoded the values and
>     inserted comments next to them referring to those macros.
> 
> It handles only st, sd_mod and sr_mod cases (as
> hotplug-ng-001/module_scsi.c did).  Are there any other?
> 
> Cheers,
>   Roman.
> 
> diff -ruNp -x '*~' linux-2.6.11-rc4.hotplug.orig/drivers/scsi/scsi_sysfs.c linux-2.6.11-rc4.hotplug/drivers/scsi/scsi_sysfs.c
> --- linux-2.6.11-rc4.hotplug.orig/drivers/scsi/scsi_sysfs.c	2005-02-13 06:05:41.000000000 +0300
> +++ linux-2.6.11-rc4.hotplug/drivers/scsi/scsi_sysfs.c	2005-02-16 04:19:07.000000000 +0300
> @@ -202,9 +202,29 @@ static int scsi_bus_match(struct device 
>  	return (sdp->inq_periph_qual = SCSI_INQ_PQ_CON)? 1: 0;
>  }
>  
> +#ifdef CONFIG_HOTPLUG

Don't ifdef it.

> +static int scsi_hotplug(struct device *dev, char **envp,
> +			int num_envp, char *buffer, int buffer_size)
> +{
> +	struct scsi_device *sdev = to_scsi_device(dev);
> +	int i = 0;
> +	int length = 0;
> +
> +	if (add_hotplug_env_var(envp, num_envp, &i, buffer, buffer_size, &length,
> +				"MODNAME=scsi-type-%d", sdev->type))
> +		return -ENOMEM;
> +
> +	envp[i] = NULL;
> +	return 0;
> +}
> +#endif
> +
>  struct bus_type scsi_bus_type = {
>          .name		= "scsi",
>          .match		= scsi_bus_match,
> +#ifdef CONFIG_HOTPLUG
> +	.hotplug	= scsi_hotplug,

No ifdef needed here either.

Other than those minor things, the patch looks good.  Care to resend it
with a "Signed-off-by:" line and the same description above (but fixed)
so I can apply it to the kernel tree?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Wed, Feb 16, 2005 at 12:11:06PM +0100, Marco d'Itri wrote:
> On Feb 16, Roman Kagan <rkagan@mail.ru> wrote:
> 
> > It handles only st, sd_mod and sr_mod cases (as
> > hotplug-ng-001/module_scsi.c did).  Are there any other?
> There is the open issue of which component should load sg.

Agreed, take that up on the linux-scsi list :)

Good luck,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Wed, Feb 16, 2005 at 01:51:17PM +0300, Roman Kagan wrote:
> It extends the hotplug multiplexor to dispatch the hotplug scripts in
> the hotplug.d/bus directory and its subdirectories matching the $MODNAME
> (with the bus: prefix stripped).

I like the idea.

> The subdirectory names would be shell patterns themselves.  (This might
> be somewhat counterintuitive because normally you want all names that
> match a pattern, but here you want all patterns (at the same time
> directory names) that match the $MODNAME.)  E.g. if someone wants a
> hotplug script to be run only for USB devices with vendor ID 0x1234 and
> product ID 0xABCD he would put his script under
> /etc/hotplug.d/usb/v1234bABCD\*/.

But having directory names as shell patterns is just too messy, I don't
see very many people accepting it (let alone understanding it...)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Greg KH]

On Sat, Feb 12, 2005 at 03:10:50PM +0300, Roman Kagan wrote:
> On Sat, Feb 12, 2005 at 03:34:58AM +0300, Roman Kagan wrote:
> > Then why not just make the kernel (and coldplug) create an additional
> > environment variable with the fnmatch-able module name ready to use with
> > modprobe?  Given that kernel (and coldplug) have all the IDs in the nice
> > integer form it would be a matter of a single add_hotplug_env_var() (or
> > sprintf()) call per each device type, and would be even tinier that the
> > hotplug-ng :)
> 
> To illustrate this with an example, here's what could be done in place
> of hotplug-ng-001/module_usb.c:

I like it a lot.  Care to resend this with a Signed-off-by: line so I
can apply it to the kernel tree?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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: [ANNOUNCE] hotplug-ng 001 release

[Roman Kagan]

On Fri, Feb 25, 2005 at 02:12:07PM -0800, Greg KH wrote:
> On Sat, Feb 12, 2005 at 03:10:50PM +0300, Roman Kagan wrote:
> > To illustrate this with an example, here's what could be done in place
> > of hotplug-ng-001/module_usb.c:
> 
> I like it a lot.  Care to resend this with a Signed-off-by: line so I
> can apply it to the kernel tree?

Sure.  But I'd like to know first if you accept my patch to
scripts/mod/file2alias.c, because it'd require a small modification to
this one, putting more sense into the string it generates :)

Besides, should I consider MODNAME agreed upon?  Given it's potential
use in hotplug not only for modprobing but as a more general matcher,
wouldn't something like DEVALIAS be a better variable name?  (Not that
the name is too important, though.)

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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