All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] path_id: Re-introduce SAS phy enumeration of devices
@ 2012-04-02 12:56 Nils Carlson
  2012-04-02 13:35 ` Hannes Reinecke
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: Nils Carlson @ 2012-04-02 12:56 UTC (permalink / raw)
  To: linux-hotplug

When path_id was converted to C code the enumeration of SAS
devices by phy disappeared. This patch reintroduces enumeration
of the form

pci-0000:05:00.0-sas-phy0:1-0x500000e114de2b42:0-lun0

where phy0:1 is the reintroduced substring where 0 corresponds
to the lowest phy identifier on the port to which the device
is connected and 1 is the number of phys on the port.

Please test this patch thoroughly as it has only been tested
with an older version of udev.

Signed-off-by: Nils Carlson <nils.carlson@ericsson.com>
---
 src/udev-builtin-path_id.c |   80 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/src/udev-builtin-path_id.c b/src/udev-builtin-path_id.c
index a8559d2..c575fd4 100644
--- a/src/udev-builtin-path_id.c
+++ b/src/udev-builtin-path_id.c
@@ -121,13 +121,67 @@ out:
         return parent;
 }
 
+static int get_sas_port_phy_id(struct udev *udev, const char *phy_name)
+{
+        struct udev_device *phydev;
+        const char *phy_id_str;
+        int phy_id = -1;
+
+        phydev = udev_device_new_from_subsystem_sysname(udev, "sas_phy",
+                                                        phy_name);
+        if (phydev = NULL) {
+                return -1;
+        }
+
+        phy_id_str = udev_device_get_sysattr_value(phydev, "phy_identifier");
+        if (phy_id_str = NULL) {
+                goto out;
+        }
+
+        phy_id = atoi(phy_id_str);
+
+out:
+        udev_device_unref(phydev);
+
+        return phy_id;
+}
+
+static int get_sas_port_num_phys(struct udev *udev, const char *port_name)
+{
+        struct udev_device *portdev;
+        const char *num_phys_str;
+        int num_phys = -1;
+
+        portdev = udev_device_new_from_subsystem_sysname(udev, "sas_port",
+                                                         port_name);
+        if (portdev = NULL) {
+                return -1;
+        }
+
+        num_phys_str = udev_device_get_sysattr_value(portdev, "num_phys");
+        if (num_phys_str = NULL) {
+                goto out;
+        }
+
+        num_phys = atoi(num_phys_str);
+
+out:
+        udev_device_unref(portdev);
+
+        return num_phys;
+}
+
 static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **path)
 {
         struct udev *udev  = udev_device_get_udev(parent);
         struct udev_device *targetdev;
         struct udev_device *target_parent;
         struct udev_device *sasdev;
+	struct udev_device *portdev;
+	struct udev_list_entry *list_entry;
         const char *sas_address;
+	int tmp_phy_id, phy_id = 255;
+	int num_phys;
         char *lun = NULL;
 
         targetdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_target");
@@ -138,6 +192,29 @@ static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa
         if (target_parent = NULL)
                 return NULL;
 
+	portdev = udev_device_get_parent(target_parent);
+	if (target_parent = NULL)
+		return NULL;
+
+	udev_list_entry_foreach(list_entry,
+				udev_device_get_sysattr_list_entry(portdev)) {
+		const char *name = udev_list_entry_get_name(list_entry);
+
+		if (strncmp(name, "phy", 3) != 0)
+			continue;
+
+		tmp_phy_id = get_sas_port_phy_id(udev, name);
+		if (tmp_phy_id >= 0 && tmp_phy_id < phy_id)
+			phy_id = tmp_phy_id;
+	}
+	if (phy_id = 255)
+		return NULL;
+
+	num_phys = get_sas_port_num_phys(udev,
+					 udev_device_get_sysname(portdev));
+	if (num_phys < 0)
+		return NULL;
+
         sasdev = udev_device_new_from_subsystem_sysname(udev, "sas_device",
                                 udev_device_get_sysname(target_parent));
         if (sasdev = NULL)
@@ -150,7 +227,8 @@ static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa
         }
 
         format_lun_number(parent, &lun);
-        path_prepend(path, "sas-%s-%s", sas_address, lun);
+	path_prepend(path, "sas-phy%d:%d-%s-%s", phy_id, num_phys,
+		     sas_address, lun);
         if (lun)
                 free(lun);
 out:
-- 
1.7.9.4


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices
  2012-04-02 12:56 [PATCH] path_id: Re-introduce SAS phy enumeration of devices Nils Carlson
@ 2012-04-02 13:35 ` Hannes Reinecke
  2012-04-02 13:55 ` Nils Carlson
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Hannes Reinecke @ 2012-04-02 13:35 UTC (permalink / raw)
  To: linux-hotplug

Hi Nils,

Thanks a lot for this. It definitely a step in the correct
direction. However, I have some comments to make:

On 04/02/2012 02:56 PM, Nils Carlson wrote:
> When path_id was converted to C code the enumeration of SAS
> devices by phy disappeared. This patch reintroduces enumeration
> of the form
> 
> pci-0000:05:00.0-sas-phy0:1-0x500000e114de2b42:0-lun0
> 
> where phy0:1 is the reintroduced substring where 0 corresponds
> to the lowest phy identifier on the port to which the device
> is connected and 1 is the number of phys on the port.
> 
I would rather not do this.
First of all, I doubt we need the overall number of phys here.
Secondly, James B. assured me that the phy enumeration is pretty much
stable, so we should be able to use that number as-is.

Also, there is a 1:1 match between the 'phy_identifier' sysfs attribute
and the second number of the phy name itself (the first number is the
SCSI host number), so we could as well just parse the phy name and get
the number from there.
But, of course, reading the phy_identifier is okay, too.

So I would propose just to insert a 'phy1' there.

But again, thanks for doing it.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices
  2012-04-02 12:56 [PATCH] path_id: Re-introduce SAS phy enumeration of devices Nils Carlson
  2012-04-02 13:35 ` Hannes Reinecke
@ 2012-04-02 13:55 ` Nils Carlson
  2012-04-03  8:04 ` [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2 Nils Carlson
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Nils Carlson @ 2012-04-02 13:55 UTC (permalink / raw)
  To: linux-hotplug

Hi Hannes,

On 04/02/2012 03:35 PM, Hannes Reinecke wrote:
> Hi Nils,
>
> Thanks a lot for this. It definitely a step in the correct
> direction. However, I have some comments to make:
>
> On 04/02/2012 02:56 PM, Nils Carlson wrote:
>> where phy0:1 is the reintroduced substring where 0 corresponds
>> to the lowest phy identifier on the port to which the device
>> is connected and 1 is the number of phys on the port.
>>
> I would rather not do this.
> First of all, I doubt we need the overall number of phys here.
> Secondly, James B. assured me that the phy enumeration is pretty much
> stable, so we should be able to use that number as-is.

I agree this would be clean, the problem is that it represents an API 
change; one could argue though that that API change has already been 
made through the breakage though.

> Also, there is a 1:1 match between the 'phy_identifier' sysfs attribute
> and the second number of the phy name itself (the first number is the
> SCSI host number), so we could as well just parse the phy name and get
> the number from there.
> But, of course, reading the phy_identifier is okay, too

Yes, this would of course also work, though I think reading the 
phy_identifier is cleaner.
.
>
> So I would propose just to insert a 'phy1' there.

I will need to check that nobody has coded the phyX:Y format into any 
scripts, hopefully the answer is no.

Cheers,
Nils

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2
  2012-04-02 12:56 [PATCH] path_id: Re-introduce SAS phy enumeration of devices Nils Carlson
  2012-04-02 13:35 ` Hannes Reinecke
  2012-04-02 13:55 ` Nils Carlson
@ 2012-04-03  8:04 ` Nils Carlson
  2012-04-03 18:24 ` Kay Sievers
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Nils Carlson @ 2012-04-03  8:04 UTC (permalink / raw)
  To: linux-hotplug

Changes since v1:
* Remove the number of phys from the output
* Extract the phy identifier from the symlink, less code.

When path_id was converted to C code the enumeration of SAS
devices by phy disappeared. This patch reintroduces enumeration
of the form

pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0

where phy0 is the reintroduced substring where 0 corresponds
to the lowest phy identifier on the port to which the device
is connected.

Please test this patch thoroughly as it has only been tested
with an older version of udev.

Signed-off-by: Nils Carlson <nils.carlson@ericsson.com>
---
 src/udev-builtin-path_id.c |   30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/src/udev-builtin-path_id.c b/src/udev-builtin-path_id.c
index a8559d2..54b22c4 100644
--- a/src/udev-builtin-path_id.c
+++ b/src/udev-builtin-path_id.c
@@ -127,7 +127,10 @@ static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa
         struct udev_device *targetdev;
         struct udev_device *target_parent;
         struct udev_device *sasdev;
+	struct udev_device *portdev;
+	struct udev_list_entry *list_entry;
         const char *sas_address;
+	int tmp_phy_id, phy_id = 255;
         char *lun = NULL;
 
         targetdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_target");
@@ -138,6 +141,31 @@ static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa
         if (target_parent = NULL)
                 return NULL;
 
+	portdev = udev_device_get_parent(target_parent);
+	if (target_parent = NULL)
+		return NULL;
+
+	udev_list_entry_foreach(list_entry,
+				udev_device_get_sysattr_list_entry(portdev)) {
+		const char *name = udev_list_entry_get_name(list_entry);
+		char *phy_id_str;
+
+		if (strncmp(name, "phy", 3) != 0)
+			continue;
+
+		phy_id_str = strstr(name, ":");
+		if (phy_id_str = NULL)
+			continue;
+
+		phy_id_str++;
+
+		tmp_phy_id = atoi(phy_id_str);
+		if (tmp_phy_id >= 0 && tmp_phy_id < phy_id)
+			phy_id = tmp_phy_id;
+	}
+	if (phy_id = 255)
+		return NULL;
+
         sasdev = udev_device_new_from_subsystem_sysname(udev, "sas_device",
                                 udev_device_get_sysname(target_parent));
         if (sasdev = NULL)
@@ -150,7 +178,7 @@ static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa
         }
 
         format_lun_number(parent, &lun);
-        path_prepend(path, "sas-%s-%s", sas_address, lun);
+	path_prepend(path, "sas-phy%d-%s-%s", phy_id, sas_address, lun);
         if (lun)
                 free(lun);
 out:
-- 
1.7.9.4


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2
  2012-04-02 12:56 [PATCH] path_id: Re-introduce SAS phy enumeration of devices Nils Carlson
                   ` (2 preceding siblings ...)
  2012-04-03  8:04 ` [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2 Nils Carlson
@ 2012-04-03 18:24 ` Kay Sievers
  2012-04-03 20:25 ` Hannes Reinecke
  2012-04-03 21:23 ` Kay Sievers
  5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2012-04-03 18:24 UTC (permalink / raw)
  To: linux-hotplug

On Tue, Apr 3, 2012 at 10:04, Nils Carlson <nils.carlson@ericsson.com> wrote:

> This patch reintroduces enumeration
> of the form
>
> pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0
>
> where phy0 is the reintroduced substring where 0 corresponds
> to the lowest phy identifier on the port to which the device
> is connected.

Without having any real insight knowledge, a quick check:

We usually refuse any "find the lowest number approach" in new code,
and require the kernel to export a stable instance number per parent
device, which is entirely disconnected from any global device
enumeration counter or prober ordering.

Almost all existing examples doing that are broken, and some even
needed to be removed because they just blindly bet on luck that things
are always in the same probe order.

Many device can individually unbound and rebound in the kernel, so
after the rebind the same device will no longer have a smaller number
like it had before. Kernel enumeration is only in a very few cases
useful to build persistent paths.

The approach in this case is safe against individual pieces being
unregistered and registered again?

Kay

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2
  2012-04-02 12:56 [PATCH] path_id: Re-introduce SAS phy enumeration of devices Nils Carlson
                   ` (3 preceding siblings ...)
  2012-04-03 18:24 ` Kay Sievers
@ 2012-04-03 20:25 ` Hannes Reinecke
  2012-04-03 21:23 ` Kay Sievers
  5 siblings, 0 replies; 7+ messages in thread
From: Hannes Reinecke @ 2012-04-03 20:25 UTC (permalink / raw)
  To: linux-hotplug

On 04/03/2012 08:24 PM, Kay Sievers wrote:
> On Tue, Apr 3, 2012 at 10:04, Nils Carlson <nils.carlson@ericsson.com> wrote:
> 
>> This patch reintroduces enumeration
>> of the form
>>
>> pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0
>>
>> where phy0 is the reintroduced substring where 0 corresponds
>> to the lowest phy identifier on the port to which the device
>> is connected.
> 
> Without having any real insight knowledge, a quick check:
> 
> We usually refuse any "find the lowest number approach" in new code,
> and require the kernel to export a stable instance number per parent
> device, which is entirely disconnected from any global device
> enumeration counter or prober ordering.
> 
> Almost all existing examples doing that are broken, and some even
> needed to be removed because they just blindly bet on luck that things
> are always in the same probe order.
> 
> Many device can individually unbound and rebound in the kernel, so
> after the rebind the same device will no longer have a smaller number
> like it had before. Kernel enumeration is only in a very few cases
> useful to build persistent paths.
> 
> The approach in this case is safe against individual pieces being
> unregistered and registered again?
> 
Note, this is just a first step towards real configuration.

This is the SAS PHY issue we've talked about earlier; eventually we'll
have to export paths for all phys.

I'm working on a patch (on top of this one), but it'll be quite a change
to path_id. So I've asked for this patch to be sent now, rather than
wait for the full blown solution.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2
  2012-04-02 12:56 [PATCH] path_id: Re-introduce SAS phy enumeration of devices Nils Carlson
                   ` (4 preceding siblings ...)
  2012-04-03 20:25 ` Hannes Reinecke
@ 2012-04-03 21:23 ` Kay Sievers
  5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2012-04-03 21:23 UTC (permalink / raw)
  To: linux-hotplug

On Tue, Apr 3, 2012 at 22:25, Hannes Reinecke <hare@suse.de> wrote:
> On 04/03/2012 08:24 PM, Kay Sievers wrote:
>> On Tue, Apr 3, 2012 at 10:04, Nils Carlson <nils.carlson@ericsson.com> wrote:
>>
>>> This patch reintroduces enumeration
>>> of the form
>>>
>>> pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0
>>>
>>> where phy0 is the reintroduced substring where 0 corresponds
>>> to the lowest phy identifier on the port to which the device
>>> is connected.
>>
>> Without having any real insight knowledge, a quick check:
>>
>> We usually refuse any "find the lowest number approach" in new code,
>> and require the kernel to export a stable instance number per parent
>> device, which is entirely disconnected from any global device
>> enumeration counter or prober ordering.
>>
>> Almost all existing examples doing that are broken, and some even
>> needed to be removed because they just blindly bet on luck that things
>> are always in the same probe order.
>>
>> Many device can individually unbound and rebound in the kernel, so
>> after the rebind the same device will no longer have a smaller number
>> like it had before. Kernel enumeration is only in a very few cases
>> useful to build persistent paths.
>>
>> The approach in this case is safe against individual pieces being
>> unregistered and registered again?
>>
> Note, this is just a first step towards real configuration.
>
> This is the SAS PHY issue we've talked about earlier; eventually we'll
> have to export paths for all phys.
>
> I'm working on a patch (on top of this one), but it'll be quite a change
> to path_id. So I've asked for this patch to be sent now, rather than
> wait for the full blown solution.

Yeah, sure, I just need to make sure we do not do things like this any more:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/udev-builtin-path_id.c;h¨559d2dd4118ac89feb03b7db8ef364caa73a0b;hb=HEAD#l255

It is just broken, and the kernel needs to export that if we really
want to use it in userspace. The kernel device name has zero meaning
and we must not derive any order from it, never. Re-registering the
same device will probably just break that too-simple logic.

I just asked, because the requirement for new stuff is much higher
today, we do not fiddle around with broken kernel interfaces anymore.
If the stuff does not export the proper things, we just don't support
it.

The time to fiddle with symptoms is over. We either get it fixed for
real, or it will just not show up in new things in higher levels in
userspace, including new symlinks udev creates.

And the transport classes in sysfs are just a nightmare; but I know, I
don't need to tell you. :)

Kay

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-04-03 21:23 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-02 12:56 [PATCH] path_id: Re-introduce SAS phy enumeration of devices Nils Carlson
2012-04-02 13:35 ` Hannes Reinecke
2012-04-02 13:55 ` Nils Carlson
2012-04-03  8:04 ` [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2 Nils Carlson
2012-04-03 18:24 ` Kay Sievers
2012-04-03 20:25 ` Hannes Reinecke
2012-04-03 21:23 ` Kay Sievers

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.