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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
