4 ms·

I'm not understanding the question here at all, sorry, can you please rephrase it? And if you have questions about how this happened, look at the source for wh

by gregkh 5y ago

I'm not understanding the question here at all, sorry, can you please rephrase it? And if you have questions about how this happened, look at the source for when it was merged, it's all there for everyone to review :) Also, udevd is a program, not a library.

totony 5y ago
As I understand there was some shared code between the two projects and udev was refactored into using systemd's code. Why not make systemd re-use udev code instead? Aka either expand udev's library or make a library out of the shared code that's used by both systemd and udev. That way udev stays a separate project and you don't have to bring in a big library to use it. Systemd needs udev both ways so it changes nothing for it apart perhaps a bit of maintenance for a separate library for the shared code.
- 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.

by gregkh 5y ago

totony 5y ago

As I understand there was some shared code between the two projects and udev was refactored into using systemd's code. Why not make systemd re-use udev code instead? Aka either expand udev's library or make a library out of the shared code that's used by both systemd and udev. That way udev stays a separate project and you don't have to bring in a big library to use it. Systemd needs udev both ways so it changes nothing for it apart perhaps a bit of maintenance for a separate library for the shared code.

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.