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

[Kay Sievers]

----- Original Message -----
> Dne 23.9.2014 v 19:55 Kay Sievers napsal(a):
> > ----- 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.
> >
> 
> Hi
> 
> Nice to see there is finally recognized the need to have separate subsystem
> management.
> 
> Now - is there some 'plugin'-like interface so we could get an embedded code
> to be executed right with  udev scanning process ?
> 
> I can see a tons of code for i.e. btrfs handling to be wired into udev.
> I believe this is also something that should be handled externally from udev
> (btrfs-progs  udev plugin ?)
> 
> Anyway - we would like to eliminate number of forked dmsetup calls
> and even further eliminate rule processing when we detect i.e. internal lvm
> device.
> 
> When we activate i.e. 1000LVs there is literally storm of forked processes
> and
> I think we can do much better.
> 
> Since there is already 'blkid' being built-in - we could solve problem
> partially by enhancing blkid detection - but still there are some things we
> can't handle within  blkid (parsing DM  names)
> 
> It would be nice to have some plugin API here where we could avoid forking
> process to do rather trivial 'string-manipulation' stuff.
> 
> 
> > New features need to happen in an existing or new storage related-package
> > and not in the systemd/udev code base.
> 
> So any plans on udev plugin API  (since rules are simply way to slow and
> inefficient)

No, there are no plans to provide shared code plugins and it is very unlikely
to happen.

External things need to be forked, udev does not want to run external code
in its address space.

Sorry,
Kay