Some basic questions on udev usage

Some basic questions on udev usage

[Allexio Ju]

Hi,

I've got some basic question.
I've been reading udev related documents and playing with latest udev
source package for a while trying to undestand persistent device
binding.
Questions are,
1. Does all of storage vendors need to have their own .rules file
under /etc/udev/rules.d? Or 60-storage-persistent.rules file should be
good enough for them?
2. If I have following filter in my own 20-private.rules file, will it
replace default device file given by kernel with my-disk, or both of
them will be there in /dev directory?
    KERNEL=sda, NAME="my-disk"
3. I'm trying to find right way to implement persistent device
binding. Let's say, I have 3 disks connected to my SCSI controller.
Consider they are: a segate in ID 0, a quantum in ID 1, and a maxtor
in ID2.
If I use following filter in my 20-private.rules file, I believe it
should work and keep persistent device name across reboot (and
inter-changes SCSI IDs among them before each boot).
    KERNEL="sd*[0-9]", BUS="pci", SYSFS{driver}="qla1280",
PROGRAM="/sbin/scsi_id –p 0x83 –g –s /block/%k",
NAME="qlgc-disk-%c-part-%n"
Is this right approach?
I just want to make sure this is right approach and would like to know
if there is better way.

Thank you,

Allexio

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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: Some basic questions on udev usage

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 2007 bytes --]

Allexio Ju wrote:
> 1. Does all of storage vendors need to have their own .rules file 
> under /etc/udev/rules.d? Or 60-storage-persistent.rules file should
> be good enough for them?

It should work for every "known" disk type (including SCSI), yes.

> 2. If I have following filter in my own 20-private.rules file, will
> it replace default device file given by kernel with my-disk, or both
> of them will be there in /dev directory?
>      KERNEL==sda, NAME="my-disk"

You will overwrite the device node name.  (I am going to assume here
that your rule really has KERNEL=="sda" in it, because AFAIK the other
isn't valid.)  With this rule in place, you will have a device node
named /dev/my-disk, not /dev/sda.

(If you need both, then use SYMLINK+= instead of NAME=, just like all
the current persistent storage rules do.  ;-))

That is, unless a subsequent rule also assigns to NAME, but AFAIK none
of those should exist.

>      KERNEL=="sd*[0-9]", BUS=="pci", SYSFS{driver}=="qla1280", 
> PROGRAM="/sbin/scsi_id –p 0x83 –g –s /block/%k", 
> NAME="qlgc-disk-%c-part-%n"
> Is this right approach?

I don't think so; you should probably use symlinks instead of renaming
the node.  That way you can refer to it by multiple names.

Look around in /dev/disk/by-id/ and /dev/disk/by-path/ to see if either
of those sets of symlinks already contain what you need.  They're put
there by the persistent storage rules.

As for the rule itself, scsi_id is already run on any SCSI-type (but not
USB) block device, though it's run in 60-persistent-storage.rules, so if
your custom rules file uses its output, it'll have to be renamed.  And
it's meant to be called as an IMPORT{program}, not just as a PROGRAM
(its output is a set of environment variables, I think).  Also, the
persistent-storage file is more general (it runs on non-PCI buses, for
all drivers, and for whole-disk devices as well as partitions).  And of
course, that rule is already written.  ;-)


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

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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: Some basic questions on udev usage

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 3081 bytes --]

(Please also reply to the list, so that others can see and respond.
Thanks!  :-))

Allexio Ju wrote:
> What if I want to make application (configuration utility) that came
> with SCSI controller recognize persistently binded device file?

I assume that the config utility has a way to specify a device node,
right?  Or does it only search for a hard-coded name?  If it only
searches for a hard-coded name, then you'll need to add a custom rule so
that name exists, yes.  Otherwise, just specify one of the by-* symlinks.

> Following question explains where I am. Upon given SYMLINK files 
> under /dev/disk/by-id and /dev/disk/uuid (I couldn't find by-path 
> under /dev/disk directory?),

Your distro may not have provided path_id and the supporting files; when
they built udev, they should have had extras/path_id set in EXTRAS.
That's assuming your udev is relatively recent, though; perhaps it's too
old?  What version?

> 1. User wants to modify menu.lst file under /boot/grub so that it 
> calls persistently binded device file instead.

Grub doesn't use Linux device names in menu.lst, does it?  I thought it
used its own naming scheme.  (That is, (hd0,0) and friends.)  AFAIK you
can't change that.

(However, newer versions of grub may have added support for this, I'm
not sure.  But given that grub runs before the kernel can interpret any
kind of request on these device files anyway (because the kernel's not
running yet), I suspect that this kind of configuration is broken
anyway.)

Now lilo, on the other hand, can use any device or symlink, because it
interprets these when /sbin/lilo is run, and at that point the devices
and symlinks do exist, and the kernel can interpret requests made on them.

> 2. Let's say, I want to make the configuration utility to recognize
> those SYMLINKs instead of current default kernel name, is it possible
> to achieve without having vendor specific .rules file under 
> /etc/udev/rule.d directory?

Sure: when you're writing your configuration utility, allow the user to
override the choice of device node.  Then they can specify anything they
want to.  ;-)  (But that's probably not much help for the automatic case.)

Basically, you want to be able to see only disks on the controller that
your configuration utility is for, correct?  That might be a little hard
with the by-id and by-uuid symlinks, because those will depend on the
disk, not the controller.  However, by-path may be helpful if your udev
has support for it; on my machine (udev-103), I see this kind of symlink
in there:

/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0
/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0-part1

You could take the beginning part of that name (pci-0000:03:00.0) and
look it up in sysfs (/sys/bus/pci/devices/0000:03:00.0, but that may be
an old symlink since I still run 2.6.18.x).  If the driver symlink in
that directory points at your driver's sysfs directory, then it's a
valid device.  But I don't think there's any persistent by-driver
support at this point.


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

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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: Some basic questions on udev usage

[Allexio Ju]

Hi,

On 1/7/07, Bryan Kadzban <bryan@kadzban.is-a-geek.net> wrote:
> > Following question explains where I am. Upon given SYMLINK files
> > under /dev/disk/by-id and /dev/disk/uuid (I couldn't find by-path
> > under /dev/disk directory?),
>
> Your distro may not have provided path_id and the supporting files; when
> they built udev, they should have had extras/path_id set in EXTRAS.
> That's assuming your udev is relatively recent, though; perhaps it's too
> old?  What version?
The version on my is udev-085-30.10 and it is running on 2.6.19 vanila kernel.

> Grub doesn't use Linux device names in menu.lst, does it?  I thought it
> used its own naming scheme.  (That is, (hd0,0) and friends.)  AFAIK you
> can't change that.
>
> (However, newer versions of grub may have added support for this, I'm
> not sure.  But given that grub runs before the kernel can interpret any
> kind of request on these device files anyway (because the kernel's not
> running yet), I suspect that this kind of configuration is broken
> anyway.)
I am referring menu.lst file that is available on 2.6.19 vanila
kernel. On the file, I thought I could modify 'root=/dev/sda2' to
'root=/dev/my-disk' from following entry in the file after I create
new initrd image that has udev infra structure.
    title Linux-2.6.19
        kernel (hd0,1)/boot/Linux-2.6.19 root=/dev/sda2 vga=1 resume=/dev/sda1
        console=ttyS0,115200 console=tty0 nmi_watchdog=1

Is this O.K?

> > 2. Let's say, I want to make the configuration utility to recognize
> > those SYMLINKs instead of current default kernel name, is it possible
> > to achieve without having vendor specific .rules file under
> > /etc/udev/rule.d directory?
>
> Sure: when you're writing your configuration utility, allow the user to
> override the choice of device node.  Then they can specify anything they
> want to.  ;-)  (But that's probably not much help for the automatic case.)
>
> Basically, you want to be able to see only disks on the controller that
> your configuration utility is for, correct?  That might be a little hard
> with the by-id and by-uuid symlinks, because those will depend on the
> disk, not the controller.  However, by-path may be helpful if your udev
> has support for it; on my machine (udev-103), I see this kind of symlink
> in there:
>
> /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0
> /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0-part1
>
> You could take the beginning part of that name (pci-0000:03:00.0) and
> look it up in sysfs (/sys/bus/pci/devices/0000:03:00.0, but that may be
> an old symlink since I still run 2.6.18.x).  If the driver symlink in
> that directory points at your driver's sysfs directory, then it's a
> valid device.  But I don't think there's any persistent by-driver
> support at this point.
I got it. Then, I can use _by-path_ to achieve my goal as far as it is
available.
As a backup plan, having my own .rule file which has
'SYSFS{driver}=my_driver' as a filter makes sense?

One more question.
All .rules file under /etc/udev/rules.d start with number. If (really
if) I want to have my own .rules file, what number should I consider
as part of my file name?
Are there any such guideline?

Regards,

Allexio

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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: Some basic questions on udev usage

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 07 January 2007 18:18, Allexio Ju wrote:
>
> I am referring menu.lst file that is available on 2.6.19 vanila
> kernel. On the file, I thought I could modify 'root=/dev/sda2' to
> 'root=/dev/my-disk' from following entry in the file after I create
> new initrd image that has udev infra structure.
>     title Linux-2.6.19
>         kernel (hd0,1)/boot/Linux-2.6.19 root=/dev/sda2 vga=1
> resume=/dev/sda1 console=ttyS0,115200 console=tty0 nmi_watchdog=1
>
> Is this O.K?
>

If you ensure that initrd is able to create this name. Most persistent rules 
require non-trivial infrastructure (they call shell scripts that in turn call 
grep/sed/awk/...; they use *_id tools that are built against libc and 
libvolume_id and possibly require some more libraries). So you end up either 
maintaining two versions of rules (one for initrd one for booted system) or 
making initrd pretty big by putting large number of tools there. Both have 
obvious drawbacks although I'd say size of initrd is not that important 
now-a-days. More serious is simple observation that you do not have any 
automated way to find out what is required by udev rules.

It may be possible to automatically create specific rule for initrd that 
generates persistent name for a given root partition. I expect that when (if) 
major numbers become really dynamic, this is what will be done anyway.
akes sense?
>
> One more question.
> All .rules file under /etc/udev/rules.d start with number. If (really
> if) I want to have my own .rules file, what number should I consider
> as part of my file name?
> Are there any such guideline?

If you want to override default rules, add your own in the beginning. If you 
want to augment - add them in the end. Try to not override anything unless 
you know well what you are doing (as example - renaming disks away from sd* 
or hd* likely renders most tools that autodetect HDDs unusable). If you need 
to have specific name - *add* it as SYMLINK; never ever use NAME :)

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFoRd7R6LMutpd94wRAhGbAJ9oAyEokylwaAEp8ZPaY065+6GW5gCcCSlw
b9GE8WqtJ1wjOk4F6ch0610)Qa
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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: Some basic questions on udev usage

[Alexander E. Patrakov]

Andrey Borzenkov wrote:
> More serious is simple observation that you do not have any 
> automated way to find out what is required by udev rules.

<joke>
http://cvs.fedora.redhat.com/viewcvs/devel/bash/bash-requires.patch

You run "bash --rpm-requires /path/to/the/script" and it outpus an 
incomplete list of its dependencies.
</joke>

-- 
Alexander E. Patrakov

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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: Some basic questions on udev usage

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 1932 bytes --]

Allexio Ju wrote:
> The version on my is udev-085-30.10 and it is running on 2.6.19
> vanila kernel.

Ah.  The kernel is probably OK, but I'm not sure when the path_id stuff
got added to udev; I'm guessing it's later than 085.  That's probably
why you don't have the /dev/disk/by-path/ directory.

085 is almost a year old now, so it's probably good to upgrade anyway
(if your distro has a newer version).

> I thought I could modify 'root=/dev/sda2'

Ah, I see.  You were talking about the kernel command line.  I thought
you meant the grub syntax, like its "root (hdX,Y)" option (the one that
controls which FS it will use to look for the subsequent files).

Yes, that would require initramfs or initrd support, as Andrey Borzenkov
said, so that the symlink gets created before the kernel tries to mount
the root FS (or so that the kernel doesn't even try to mount a root FS,
but leaves it up to early userspace).  If you don't run an initramfs or
initrd, then it won't work.

> As a backup plan, having my own .rule file which has 
> 'SYSFS{driver}==my_driver' as a filter makes sense?

Yeah, that's probably the easiest.  But make sure you use
SYMLINK+="whatever", as Andrey also said, so you don't overwrite
anything.  :-)

> All .rules file under /etc/udev/rules.d start with number. If (really
> if) I want to have my own .rules file, what number should I consider
> as part of my file name?

The rules files get "executed" in lexicographical order, so the number
prefix really just controls the order.  The order controls which kinds
of environment variables are available (IMPORT keys only create
environment variables for future rules) and which final NAME will take
effect (but this is something you don't usually want to change).  Oh --
it will also control the order of the values in the SYMLINKS key, but
for that, the order doesn't matter (all symlinks always get created).


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

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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