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

[Zdenek Kabelac]

Dne 24.9.2014 v 17:06 Kay Sievers napsal(a):
> ----- 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.

It's already being done - udev is using/linking libblkid - thus you run 
'external' code in udev address.

So it's just the view you take on it.

But - we just don't won't link i.e. libdm with libudev to gain knowledge in 
udev process.

So there should be a runtime way how to extend udev for performance reasons.

Of course the other way around is - to 'hack-in' udev code and add another 
chunk of code - like you did for already mentioned btrfs.

But I believe dlopening  runtime object file and using it inside  udev 
scanning process to accelerate udev rules process would be much nicer way.

Zdenek