Re: udev does not create scsi disk entries during bootup

[Greg KH <greg@kroah.com>]

On Thu, Nov 27, 2003 at 04:54:37PM +0530, Surekha.PC wrote:
> 
> Hi,
> 
> >Can you split this up into 2 different patches, both generated with
> 'diff -u' so we can 
> >see the changes easier?
> 
> I have generated the patch in the suggested format. The patch for
> appending partition name  is just a one liner, so it is part of patch
> enclosed alongwith. Line #34, is the change with this statement.
> 
> + strcat(pos, "s");

With that, you break everyone who uses the %n modifier.  Why not just
add a 's' to your NAME value?

Not applied.

> >> 1)To include new field in the NUMBER rule specially for iSCSI
> devices.
> >>  
> >> The current rule provided by udev is as below.
> >> 
> >> NUMBER, BUS="scsi", ID=2:0:0:0", NAME="disk%n"
> >> 
> >> For iSCSI devices, since hostid is not consistent, we are defining a 
> >> new iSCSI device attribute in sysfs, which will be checked while 
> >> naming the device.
> >> 
> >> NUMBER, BUS="scsi", ID="0:0:0", device_type="ISCSI", NAME="ib0t0l0%n"
> 
> >Where does the device_type come from?  Is it a sysfs file?
> 
> It is a sysfs file which is a device attribute defined for iSCSI devices
> in the iSCSI driver.
> 
> >> 2) Device partition name needs to be appended with "s" before 
> >> partition id.
> >>  
> >> If the device name consists of bus,target info like "c0b0t0l0" it
> will 
> >> be easier to identify the partition as in "c0b0t0l0s1".
> 
> >It looks like your patch just always adds a 's' whenever you use a %n
> field.  Why not 
> >just put the 's' in your NAME?  Otherwise you just broke everyone's
> rules who do not want >a 's' :)
> 
> The string 's' (it could be named as 'part' also) has be used only on
> partition names like 'sda1', 'sda2' and not on block device name 'sda'.
> So  it can't be put in the NAME field. 
> 
> Below is the how the output for iSCSI device looks with this patch. 
> 
> This will help separately identify the partition number from lun number.
> 
> #ls -l /udev
> total 0
> brw-rw-rw-    1 root     root       8,  32 Nov 27 07:17 ib0t4l0
> brw-rw-rw-    1 root     root       8,  33 Nov 27 07:17 ib0t4l0s1
> brw-rw-rw-    1 root     root       8,  34 Nov 27 07:17 ib0t4l0s2

What is driving naming iscsi devices like this?  Any LSB standard?  Any
devfs standard?

I really think you can handle all of this for iscsi devices with a
CALLOUT script that can handle this more complex way of creating a name.

> >Can't you do everything you need with a simple callout script right now
> with no changes 
> >needed for udev?
> 
> Persistent naming of iSCSI devices require bus, target and lun info.
> This is in conjunction with persistent target binding done internally in
> our driver where we bind each iSCSI device to a unique bus/target pair
> based on the iSCSI targetname.

Why?  What if I want to name my iscsi device "greg_server_storage"?
What is forcing users to use bus, target, and lun info?

> In a case where there are many targets connected to iSCSI host,
> udev.config is automatically generated by looking up the bus and target
> id allocated for the iSCSI device.

What tool modifies udev.config automatically today?

> This needs to be matched with iSCSI specific device attribute
> 'device_type' to make sure this naming applies only for a iSCSI device.
> It is not possible to achieve this funtionality with CALLOUT
> configuration.

Again, why?  What about:
CALLOUT, BUS="scsi", PROGRAM="/sbin/name_iscsi", ID="*", NAME="%c"

and then your program can test the 'type' value of the sysfs device
passed to it.  As most scsi device naming issues are going to be handled
by a CALLOUT rule anyway (due to a lot of the scsi device info not
available in sysfs), I don't see a big problem with this.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel