[systemd-devel] [PATCH] udevd: SAS: use SAS addr + PHY id in by-path whenever possible.

[Tomas Henzl]

On 09/24/2014 05:03 PM, Kay Sievers wrote:
> ----- Original Message -----
>> On Tue, Sep 23, 2014 at 01:55:09PM -0400, Kay Sievers wrote:
>>> ----- Original Message -----
>>>>> We are not applying this patch now. It introduces a complete new
>>>>> scheme and we do not want to extend the current SCSI code, we only
>>>>> fix obvious bugs.
>>>> Fine with me, however not sure what our story should be for years to come
>>>> regarding SCSI stuff downstream.
>>> Simple as: Don't add new features to systemd/udev, only fix bugs.

The by-path has been part of udev for a long time, the users of this
feature are from the same camp as the users of the,
'enterprise storage'. Everyone has been happily using it, 
until someone found out that the values shown are incorrect.
The patch posted here corrects the values so it can work as expected.
You probably were confused by something, but this is _not_ a new feature
it's a obvious bug fix.

Please consider again inclusion of this patch.

Tomas 

>>>
>>> SCSI code needs to be maintained by someone who understands it and is
>>> capable and willing to maintain it in the long run. Systemd/udev
>>> maintainers lack the experience and cannot do that.
>>>
>>> New features need to happen in an existing or new storage related-package
>>> and not in the systemd/udev code base.
>> Systemd+udev are supposed to be about providing a fairly complete
>> basic environment.
> No, it is absolutely not. Things like enterprise storage technology
> is for sure not part of our task. We focus on the basic operating system
> tasks only.
>
>> I don't see why an exception should be made for SAS
>> disks. If necessary, we can bring additional people in, or maybe just
>> wait for patches.
> No, we don't. We will move this out to an external package.
>
>> This seems like a better solution than waiting for
>> a project to be created to create and maintain a tiny amount of code
>> and one line of udev rules.
> It is not tiny. It is complicated and has a long history of forth and
> back. Systemd/udev is just the wrong place to maintain it.
>
>> I think that the failure mode is especially ugly here: if you have the
>> hardware, but don't install this mythical extra package, systemd/udev
>> provides one set of "stable" names. Then you install the extra
>> package, and you get a different set.
> That is how *features* work, they require extra packages. SCSI, SAS, LVM,
> MD,  enterprise storage, ... is _not_ part of systemd's task and should
> be maintained separately.
>
>>>> Kay, any serious objections to applying only
>>>> downstream for RHEL?
>>> Well, the currently created links will go away and potentially break
>>> existing users. Not sure what is acceptable here. I personally would
>>> not apply it to any released product.
>> Right, so applying the patch as is is probably not OK. But we could provide
>> the old names as an additional alias. This should be doable.
> Nope, no new features. Upstream systemd/udev will not apply or ship it.
> A new place in an externally maintained package is needed to add/improve
> the current code.
>
> Kay