udev enhancements

udev enhancements

[Hannes Reinecke]

Hi all,

I'm trying to figure out the best way to incorporating udev into some 
system tools. Currently we're facing the following problem:

Any program dealing with device nodes (e.g. parted) need to figure out 
some information about the device it handles:
- partition naming: given a device name, generate the name of a
   partition on that device.
- number of partitions: each block device type has it's own maximal
   number of partitions.

These information is mostly gathered from the device name. Of course, 
you can't do that if you're using udev.
So, to retain the existing functionality we would need to add two major 
improvements to udev:

- Build udevinfo as library. This way any program can just link to this 
library and retrieve any information from there instead of rely on some 
build-in logic. That should actually be quite simple ...
- Add a 'dry-run' logic to udev/udevinfo: Given a devicename, how would 
a partition on that device be named?

The latter is the _really_ hard part. Currently there is no relationship 
in udev between a device and the partitions associated to that device.
I would love to see that, though, as it would simplify the rules and the 
run-time behaviour of udev significantly.
With the current setup we have to re-run any program fetching 
information about the device (e.g. scsi_id) every time a new partition 
has been detected. If we had a device->partition relationship, we could 
re-use the information from the device and just paste the 
partition-specific bits to the end.

And it would also break the deadlock we're having now:
Removable IDE devices _always_ do a re-read partition on _open_.
So if we're using device_id to fetch information about a partition, 
we're triggering hotplug events for each partition, which causes 
device_id to re-run, which causes hotplug-events, which ...

Not nice. And no clean way to resolve it in kernel-land, either, as most 
removable IDE devices have no clean way to detect a media change.

So, would those two ideas acceptable? Or are there better ideas?
Or (preferably) better solutions?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
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://productguide.itmanagersjournal.com/
_______________________________________________
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: udev enhancements

[Harald Hoyer]

Hannes Reinecke wrote:
 > And it would also break the deadlock we're having now:
 > Removable IDE devices _always_ do a re-read partition on _open_.
 > So if we're using device_id to fetch information about a partition, we're
 > triggering hotplug events for each partition, which causes device_id to
 > re-run, which causes hotplug-events, which ...
 >
 > Not nice. And no clean way to resolve it in kernel-land, either, as most
 > removable IDE devices have no clean way to detect a media change.


in fedora udev-048 we use in udev.rules:
KERNEL="hd[a-z]*", BUS="ide", SYSFS{removable}="1", NAME{ignore_remove}="%k"

this prevents the removal of the device nodes.


-------------------------------------------------------
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://productguide.itmanagersjournal.com/
_______________________________________________
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: udev enhancements

[Olaf Hering]

 On Thu, Dec 16, Harald Hoyer wrote:

> KERNEL="hd[a-z]*", BUS="ide", SYSFS{removable}="1", NAME{ignore_remove}="%k"
> 
> this prevents the removal of the device nodes.

Is there a way to remove only the symlinks and leave the device nodes?
Some people are concerned about the rpm -V $foopackage output.
I dont want to argue with them.


-------------------------------------------------------
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://productguide.itmanagersjournal.com/
_______________________________________________
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: udev enhancements

[Kay Sievers]

On Thu, 2004-12-16 at 10:27 +0100, Hannes Reinecke wrote:
> I'm trying to figure out the best way to incorporating udev into some 
> system tools. Currently we're facing the following problem:
> 
> Any program dealing with device nodes (e.g. parted) need to figure out 
> some information about the device it handles:
> - partition naming: given a device name, generate the name of a
>    partition on that device.
> - number of partitions: each block device type has it's own maximal
>    number of partitions.
> 
> These information is mostly gathered from the device name. Of course, 
> you can't do that if you're using udev.

Why? You still know the sysfs path with the kernel device name in it.

> So, to retain the existing functionality we would need to add two major 
> improvements to udev:
> 
> - Build udevinfo as library. This way any program can just link to this 
> library and retrieve any information from there instead of rely on some 
> build-in logic. That should actually be quite simple ...

Why do you want to link against it? What's the problem with executing
it, which is much easier to maintain?

> - Add a 'dry-run' logic to udev/udevinfo: Given a devicename, how would 
> a partition on that device be named?

> The latter is the _really_ hard part. Currently there is no relationship 
> in udev between a device and the partitions associated to that device.
> I would love to see that, though, as it would simplify the rules and the 
> run-time behaviour of udev significantly.
> With the current setup we have to re-run any program fetching 
> information about the device (e.g. scsi_id) every time a new partition 
> has been detected. If we had a device->partition relationship, we could 
> re-use the information from the device and just paste the 
> partition-specific bits to the end.

You may just use a PROGRAM script on the partitions rule, that returns
the node name of the main block device.

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://productguide.itmanagersjournal.com/
_______________________________________________
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: udev enhancements

[Greg KH]

On Thu, Dec 16, 2004 at 10:27:59AM +0100, Hannes Reinecke wrote:
> Hi all,
> 
> I'm trying to figure out the best way to incorporating udev into some 
> system tools. Currently we're facing the following problem:
> 
> Any program dealing with device nodes (e.g. parted) need to figure out 
> some information about the device it handles:
> - partition naming: given a device name, generate the name of a
>   partition on that device.
> - number of partitions: each block device type has it's own maximal
>   number of partitions.
> 
> These information is mostly gathered from the device name. Of course, 
> you can't do that if you're using udev.
> So, to retain the existing functionality we would need to add two major 
> improvements to udev:
> 
> - Build udevinfo as library. This way any program can just link to this 
> library and retrieve any information from there instead of rely on some 
> build-in logic. That should actually be quite simple ...

Look at how HAL uses udevinfo to get this kind of information.  You
don't need to make udevinfo into a library to do this.  In fact, now
that the udev database is just a directory of files, you don't really
need udevinfo to get this yourself (just be careful if we change the
database format in the future...)

> - Add a 'dry-run' logic to udev/udevinfo: Given a devicename, how would 
> a partition on that device be named?

Look at udevtest, that provides a "dry-run" functionality.

> And it would also break the deadlock we're having now:
> Removable IDE devices _always_ do a re-read partition on _open_.
> So if we're using device_id to fetch information about a partition, 
> we're triggering hotplug events for each partition, which causes 
> device_id to re-run, which causes hotplug-events, which ...

Use {all_partitions} for such devices.  Linus has even argued that udev
itself should do this by default for these types of things just to make
it simpler.

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://productguide.itmanagersjournal.com/
_______________________________________________
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