[ANNOUNCE] udev 089 release

[ANNOUNCE] udev 089 release

[Kay Sievers]

Here comes a new udev version. Thanks to everybody who
helped finding bugs or sending fixes.

The tarball can be found here:
  ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug

The development repository can be found here:
  http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary


udev 089
====
Fix rule to skip persistent rules for removable IDE devices, which
also skipped optical IDE drives.

All *_id program are installed in /lib/udev/ by default now.

No binary is stripped anymore as this should be done in the
packaging process and not at build time.

libvolume_id is provided as a shared library now and vol_id is
linked against it. Also one of the next HAL versions will require
this library, and the HAL build process will also require the
header file to be installed. The copy of the same code in HAL will
be removed to have only a single copy left on the system.

udev 088
====
Add persistent links for SCSI tapes. The rules file is renamed
to 60-persistent-storage.rules.

Create persistent path for usb devices. Can be used for all sorts
of devices that can't be distinguished by other properties like
multiple identical keyboards and mice connected to the same box.

Provide "udevtrigger" program to request events on coldplug. The
shell script is much too slow with thousends of devices.

udev 087
====
Fix persistent disk rules to exclude removable IDE drives.

Warn if %e, $modalias or MODALIAS is used.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] udev 089 release

[David Gómez]

Hi,

On Apr 03 at 07:11:23, Kay Sievers wrote:
> Provide "udevtrigger" program to request events on coldplug. The
> shell script is much too slow with thousends of devices.

Nice solution for the generating coldplugging events ;).

BTW, with udev-089 the drm devices are not created. The rule
in my config scripts is:

KERNEL="card*",                NAME="dri/card%n", GROUP="video"

But i was having some problems with the radeon DRM module (DRI
not working), so maybe this is no udev problem, but a radeon
driver problem. I just remembered a message in this list about
drm devices so i wanted to ask to the list if this problem was
fixed.

Thanks, 

-- 
David Gómez                                      Jabber ID: davidge@jabber.org


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] udev 089 release

[Kay Sievers]

On Tue, Apr 04, 2006 at 09:46:11PM +0200, David Gómez wrote:
> 
> BTW, with udev-089 the drm devices are not created. The rule
> in my config scripts is:
> 
> KERNEL="card*",                NAME="dri/card%n", GROUP="video"

Greg has fixed it and it works for me. What kernel is it?

Kay


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
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] udev 089 release

[David Gómez]

Hi Kay,

On Apr 04 at 09:51:10, Kay Sievers wrote:
> > KERNEL="card*",                NAME="dri/card%n", GROUP="video"
> 
> Greg has fixed it and it works for me. What kernel is it?

2.6.16. I think the radeon module is having problems detecting the card (X300).

Thanks for the fast reply ;)

-- 
David Gómez                                      Jabber ID: davidge@jabber.org


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] udev 089 release

[Kay Sievers]

On Tue, Apr 04, 2006 at 09:56:16PM +0200, David Gómez wrote:
> Hi Kay,
> 
> On Apr 04 at 09:51:10, Kay Sievers wrote:
> > > KERNEL="card*",                NAME="dri/card%n", GROUP="video"
> > 
> > Greg has fixed it and it works for me. What kernel is it?
> 
> 2.6.16. I think the radeon module is having problems detecting the card (X300).

You probably need a new X server:
  http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;hódd5c37382472a8b245ad791ed768771594e60c

Kay


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
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] udev 089 release

[Scott James Remnant]

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

On Mon, 2006-04-03 at 19:11 +0200, Kay Sievers wrote:

> Provide "udevtrigger" program to request events on coldplug. The
> shell script is much too slow with thousends of devices.
> 
How does this differ from our "udevplug" ? :)

Would it be worth consolidating both into the same tool?

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [ANNOUNCE] udev 089 release

[Kay Sievers]

On Wed, Apr 05, 2006 at 12:25:34AM +0100, Scott James Remnant wrote:
> On Mon, 2006-04-03 at 19:11 +0200, Kay Sievers wrote:
> 
> > Provide "udevtrigger" program to request events on coldplug. The
> > shell script is much too slow with thousends of devices.
> > 
> How does this differ from our "udevplug" ? :)

It simply triggers events for all devices. And the logic to wait for
the queue to become empty is in a different tool.

> Would it be worth consolidating both into the same tool?

If you can convince me why we would want to filter out events on the
event generation side instead of doing that on the event handling side.
I'm not sure about the idea of controlling the module load order or the
other weird things that way, but you may may have good reasons I don't
see at the moment.

Kay


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] udev 089 release

[Scott James Remnant]

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

On Wed, 2006-04-05 at 20:51 +0200, Kay Sievers wrote:

> On Wed, Apr 05, 2006 at 12:25:34AM +0100, Scott James Remnant wrote:
> > On Mon, 2006-04-03 at 19:11 +0200, Kay Sievers wrote:
> > 
> > > Provide "udevtrigger" program to request events on coldplug. The
> > > shell script is much too slow with thousends of devices.
> > > 
> > How does this differ from our "udevplug" ? :)
> 
> It simply triggers events for all devices. And the logic to wait for
> the queue to become empty is in a different tool.
> 
> > Would it be worth consolidating both into the same tool?
> 
> If you can convince me why we would want to filter out events on the
> event generation side instead of doing that on the event handling side.
> I'm not sure about the idea of controlling the module load order or the
> other weird things that way, but you may may have good reasons I don't
> see at the moment.
> 
The principal reason for us at the moment is in the initramfs; in the
main system we just plug everything and let the order be damned.
Indeed, wherever we've found a situation where a module load order is
necessary (I know of three or four I think at the moment) we've decided
that the bug is in the driver for requiring that order.

In the initramfs, we exercise a little more caution; making sure that we
only probe PCI IDE or SCSI controllers first before we move on to
probing for USB buses.  The reasoning for this is that we don't want
someone's fast USB pen drive beating their SATA or SCSI disk to
getting /dev/sda1

This may be unique to Ubuntu where we try to have an initramfs image
that can do everything, rather than customising it per-install; but then
for us being able to move an installation between machines and have it
always boot has been an important goal.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [ANNOUNCE] udev 089 release

[Marco d'Itri]

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

On Apr 05, Scott James Remnant <scott@ubuntu.com> wrote:

> In the initramfs, we exercise a little more caution; making sure that we
> only probe PCI IDE or SCSI controllers first before we move on to
> probing for USB buses.  The reasoning for this is that we don't want
> someone's fast USB pen drive beating their SATA or SCSI disk to
> getting /dev/sda1
Why would this be a bad?

> This may be unique to Ubuntu where we try to have an initramfs image
> that can do everything, rather than customising it per-install; but then
Debian does too, and it loads everything.

-- 
ciao,
Marco

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

Re: [ANNOUNCE] udev 089 release

[juuso.alasuutari]

Quoting Scott James Remnant <scott@ubuntu.com>:

> > If you can convince me why we would want to filter out events on the
> > event generation side instead of doing that on the event handling side.
> > I'm not sure about the idea of controlling the module load order or the
> > other weird things that way, but you may may have good reasons I don't
> > see at the moment.
> >
> The principal reason for us at the moment is in the initramfs; in the
> main system we just plug everything and let the order be damned.
> Indeed, wherever we've found a situation where a module load order is
> necessary (I know of three or four I think at the moment) we've decided
> that the bug is in the driver for requiring that order.

I just wanted to pop in to confirm that network device modules loading in random
order can be a pain. When interfaces are not always named in the same order,
things can become more complicated than they should be.
This can of course be avoided with rules that bind MAC addresses to fixed names,
but it would be much nicer to have a predictable loading order.

Juuso

----------------------------------------------------------------
This mail sent through L-secure: http://www.l-secure.net/



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [ANNOUNCE] udev 089 release

[Scott James Remnant]

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

On Wed, 2006-04-05 at 21:36 +0200, Marco d'Itri wrote:

> On Apr 05, Scott James Remnant <scott@ubuntu.com> wrote:
> 
> > In the initramfs, we exercise a little more caution; making sure that we
> > only probe PCI IDE or SCSI controllers first before we move on to
> > probing for USB buses.  The reasoning for this is that we don't want
> > someone's fast USB pen drive beating their SATA or SCSI disk to
> > getting /dev/sda1
> Why would this be a bad?
> 
root=/dev/sda1 ... "uh, why did it try and mount my iPod as the root
disk?"

(Orthogonal to the "use UUID/Label" argument).

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [ANNOUNCE] udev 089 release

[Greg KH]

On Thu, Apr 06, 2006 at 03:54:17AM +0300, juuso.alasuutari@tamperelainen.org wrote:
> Quoting Scott James Remnant <scott@ubuntu.com>:
> 
> > > If you can convince me why we would want to filter out events on the
> > > event generation side instead of doing that on the event handling side.
> > > I'm not sure about the idea of controlling the module load order or the
> > > other weird things that way, but you may may have good reasons I don't
> > > see at the moment.
> > >
> > The principal reason for us at the moment is in the initramfs; in the
> > main system we just plug everything and let the order be damned.
> > Indeed, wherever we've found a situation where a module load order is
> > necessary (I know of three or four I think at the moment) we've decided
> > that the bug is in the driver for requiring that order.
> 
> I just wanted to pop in to confirm that network device modules loading in random
> order can be a pain. When interfaces are not always named in the same order,
> things can become more complicated than they should be.
> This can of course be avoided with rules that bind MAC addresses to fixed names,
> but it would be much nicer to have a predictable loading order.

Use MAC addressed to create fixed names if you really care about this.
Otherwise, the loading order is never guaranteed to be the same (pci bus
ids change, usb ids change, etc.)

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel