3 ms·

I don't want to put words in Greg's mouth, but if you check the code for udevd at this moment you can see a lot of use of utility headers that are not really ap

by zxzax 5y ago

I don't want to put words in Greg's mouth, but if you check the code for udevd at this moment you can see a lot of use of utility headers that are not really appropriate for a libudev: https://github.com/systemd/systemd/blob/c54cfef3968613f9e86e76a3337148360e20150e/src/udev/udevd.c#L30 https://github.com/systemd/systemd/blob/c54cfef3968613f9e86e... Expanding udev's library would probably end up a decent size library of other functionality, I don't think there is any good way around needing this. This is not code that could be deleted from systemd if it was separated. The way eudev has handled it is by doing what you describe and copying those shared functions out from systemd: https://github.com/gentoo/eudev/tree/34b2037d379e33f1cf79a3449b89ac2f98d546d9/src/shared https://github.com/gentoo/eudev/tree/34b2037d379e33f1cf79a34... The result of that being there are two copies of the same shared code floating around, which is what they were trying to avoid.

totony 5y ago
>but if you check the code for udevd at this moment you can see a lot of use of utility headers that are not really appropriate for a libudev: That's fair. >This is not code that could be deleted from systemd if it was separated. Why not? You could make a library out of those utility functions and use it from both systemd and udev (without having to include most of libsystemd which doesn't seem useful for udev).
- zxzax 5y ago
  I don't have a quote handy, but systemd maintainers have previously said they are not interested in also maintaining a giant public API of utility functions, on top of everything else.