3 ms·

The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Siever

by gregkh 5y ago

The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Sievers), both agreed that it made more sense to move it into the systemd codebase in order for lots of duplicated code and functionality to be removed. By doing this, we have made the maintenance and support for this core userspace tool much easier for everyone who was involved in working on it. If the developers involved in a project do not do what you want with that project, feel free to fork the project as that's the beauty of open source! And hey, that's exactly what the eudev developers did, go use their fork if you want to, no one is forcing you to use the version from systemd, just like no one is forcing you to use any other open source program. It's your choice to do so or not :)

totony 5y ago
Why did you chose udev using libsystemd and not systemd using libudev (or made a different shared library, I'm not familiar with what happened)? Seems like this would have been a more widely accepted change and achieved the same thing.
- 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

Why did you chose udev using libsystemd and not systemd using libudev (or made a different shared library, I'm not familiar with what happened)? Seems like this would have been a more widely accepted change and achieved the same thing.

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.