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

[Kay Sievers]

----- 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.
> > 
> > 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