[gregkh]

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]

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]

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]

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]

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/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/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]

>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]

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.