pattern matching in udev
Hello,
did anyone considered the idea of using pattern matching in udev.
The current mecanism is nice but it requires an exact match.
For example, I have a USB dual memory card reader which produces 2 devices (such as /block/sda and /block/sdb). They have the same characteristics (model, vendor,...). The only difference is their bus 'id' (N:0:0:0 and N:0:0:1 with N a scsi host number).
LABEL is useless because the 'keys' are identical and TOPOLOGY is also not what I want because the scsi host are not constant.
The current solution is to use CALLOUT but a better way to do it would be to add some simple pattern matching capabilities to udev.
For example using the usual * and ? :
LABEL, BUS="scsi", vendor="ImageMate CF-SM ", ID="*:0:0:0" , NAME="mem0-%n" LABEL, BUS="scsi", vendor="ImageMate CF-SM ", ID="*:0:0:1" , NAME="mem1-%n"
Or even better using regular expressions that could be reused to build the final name:
REGEXP "<$bus><$vendor><$id>"="<scsi><ImageMate.*><.*:0:0:\(.*\)>",
NAME="mem\1-%n"
S. Chauveau
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Stephane Chauveau
LABEL is useless because the 'keys' are identical and TOPOLOGY is also not what I want because the scsi host are not constant.
The current solution is to use CALLOUT but a better way to do it would be to add some simple pattern matching capabilities to udev.
Yes, that sounds like a good idea.
Quoted 10 lines
For example using the usual * and ? :
LABEL, BUS="scsi", vendor="ImageMate CF-SM ", ID="*:0:0:0" , NAME="mem0-%n" LABEL, BUS="scsi", vendor="ImageMate CF-SM ", ID="*:0:0:1" , NAME="mem1-%n"
Or even better using regular expressions that could be reused to build the final name:
REGEXP "<$bus><$vendor><$id>"="<scsi><ImageMate.*><.*:0:0:\(.*\)>",
NAME="mem\1-%n"
IMO the pattern matching should be part of the TOPOLOGY plus PLACE.
The scsi naming also requires a parent, your example above is only valid if you have one host adapter connected (or one usb mass storage device attached), there could exist another sd on *:0:0:0.
The matching should be capable of including the parent path, or more easily but uglier, the whole sysfs path.
For example:
Two usb mass storage at LUN 0 and LUN1:
/sysfs/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host0/0:0:0:0 /sysfs/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/host0/0:0:0:1
And a system with a scsi host adapter with a single device at LUN 0:
/sysfs/devices/pci0000:01/0000:01:0c.0/host1/1:0:0:0
Could be named via:
TOPOLOGY, BUS="usb", place="pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/*/*:0:0:0", NAME="mem0-%n"
TOPOLOGY, BUS="usb", place="pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0/*/*:0:0:1", NAME="mem1-%n"
TOPOLOGY, BUS="usb", place="pci0000:01/0000:01:0c.0/*/*:0:0:0" NAME="disk1%n"
-- Patrick Mansfield
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Stephane Chauveau
The current solution is to use CALLOUT but a better way to do it would be to add some simple pattern matching capabilities to udev.
For example using the usual * and ? :
LABEL, BUS="scsi", vendor="ImageMate CF-SM ", ID="*:0:0:0" , NAME="mem0-%n" LABEL, BUS="scsi", vendor="ImageMate CF-SM ", ID="*:0:0:1" , NAME="mem1-%n"
Yes, using '*' in this manner would be nice to have. Care to hack up the strncmp_wildcard() function to achieve this?
Quoted 5 lines
Or even better using regular expressions that could be reused to build the final name:
REGEXP "<$bus><$vendor><$id>"="<scsi><ImageMate.*><.*:0:0:\(.*\)>",
NAME="mem\1-%n"
Ick, if you want to do something like this, CALLOUT to a perl script :)
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Patrick Mansfield
Quoted 9 lines · Stephane Chauveau
Quoted 8 lines
Quoted 2 lines
REGEXP "<$bus><$vendor><$id>"="<scsi><ImageMate.*><.*:0:0:\(.*\)>",
NAME="mem\1-%n"IMO the pattern matching should be part of the TOPOLOGY plus PLACE.
The scsi naming also requires a parent, your example above is only valid if you have one host adapter connected (or one usb mass storage device attached), there could exist another sd on *:0:0:0.
Quoted 7 lines
Quoted 1 line
Not really because my example matches the $bus, the $id and the $vendor.
There could be another identical scsi device with the same id and vendor.
I thought the PCI sysfs id's were constant for a given hardware, but I'm told they can change with PCI hotplug, so the full sysfs path I mentioned previously will not be constant across boots with PCI hotplugging.
You cant have everything. How do you describe a filesystem to mount:
Its either the location, then the content may change, or it is the content, then the location can change (content in the sense of fs UUID).
And in the case of pci cards, there is no need for PCI hotplug. Just open your PC and move the SCSI card from slot a to slot b. result:
device node doesnt match if you go for location.
Signature · 14 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ------------------------------------------------------- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 18 lines · Patrick Mansfield
Quoted 4 lines · Stephane Chauveau
Quoted 4 lines
Quoted 4 lines
REGEXP "<$bus><$vendor><$id>"="<scsi><ImageMate.*><.*:0:0:\(.*\)>",
NAME="mem\1-%n"Quoted 10 lines
Quoted 7 lines
IMO the pattern matching should be part of the TOPOLOGY plus PLACE.
The scsi naming also requires a parent, your example above is only valid if you have one host adapter connected (or one usb mass storage device attached), there could exist another sd on *:0:0:0.
Not really because my example matches the $bus, the $id and the $vendor.
Quoted 7 lines
There could be another identical scsi device with the same id and vendor.
I thought the PCI sysfs id's were constant for a given hardware, but I'm told they can change with PCI hotplug, so the full sysfs path I mentioned previously will not be constant across boots with PCI hotplugging.
I agree that matching the vendor is not enough but this is because my example is incorrect.
What I call '$vendor' is my example is in fact the '$model'. The 'ImageMate' is an external USB memory card reader so the PCI or the SCSI ids are
not constant and cannot be used at all (except the last bit to differenciate the 2 slots on the
card reader). The only way to identify a USB device is to match the 'model' and the usb
device 'id'
Your remark about having identical devices is especially relevant in case of USB (or other
hot-plugable) devices. For example, how could udev handle 2 identical USB joysticks?
Ideally, udev should be able to create a device 'js0' for the 1st joystick plugged in, 'js1'
for the second, etc.
One accepatble way could be to use the USB topology! the joystick plugged in the nth
USB slot would be 'jsn' but that won't work with wireless devices.
Quoted 12 lines
Quoted 7 lines
A single method capable of pattern matching on all the available informations could be used to replace all the methods currently in implemented in udev (except maybe REPLACE which has a different purpose).
-- Patrick Mansfield
Stephane Chauveau
-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 20 lines · Olaf Hering
Quoted 10 lines · Patrick Mansfield
Quoted 9 lines · Stephane Chauveau
Quoted 8 lines
Quoted 2 lines
REGEXP "<$bus><$vendor><$id>"="<scsi><ImageMate.*><.*:0:0:\(.*\)>",
NAME="mem\1-%n"IMO the pattern matching should be part of the TOPOLOGY plus PLACE.
The scsi naming also requires a parent, your example above is only valid if you have one host adapter connected (or one usb mass storage device attached), there could exist another sd on *:0:0:0.
Quoted 7 lines
Quoted 1 line
Not really because my example matches the $bus, the $id and the $vendor.
There could be another identical scsi device with the same id and vendor.
I thought the PCI sysfs id's were constant for a given hardware, but I'm told they can change with PCI hotplug, so the full sysfs path I mentioned previously will not be constant across boots with PCI hotplugging.
Quoted 7 lines
You cant have everything. How do you describe a filesystem to mount:
Its either the location, then the content may change, or it is the content, then the location can change (content in the sense of fs UUID).And in the case of pci cards, there is no need for PCI hotplug. Just open your PC and move the SCSI card from slot a to slot b. result:
device node doesnt match if you go for location.
I think the primary goal should be that adding and removing of devices (or controllers) does not change the name of the old/remaning devices.
If you open the PC and redistribute the PCI-Cards to the PCI-slots you can expect that something changed.
Ihno
Signature · 21 lines
Best regards/Mit freundlichen Grüßen Ihno Krumreich "Never trust a computer you can lift." -- Ihno Krumreich [email protected] SuSE Linux AG Projectmanager S390 & zSeries Deutschherrnstr. 15-19 +49-911-74053-439 90429 Nürnberg http://www.suse.de ------------------------------------------------------- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Ihno Krumreich
If you open the PC and redistribute the PCI-Cards to the PCI-slots you can expect that something changed.
Again, if you cared about location, then you lost. If you had used the fs UUID as example then everything would continue to work.
Its up to the admin to decide what is important. You cant have both at the same time.
Signature · 14 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ------------------------------------------------------- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel