From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Mon, 01 Dec 2003 23:59:18 +0000 Subject: Re: udev does not create scsi disk entries during bootup Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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