1 |
Greg KH wrote: |
2 |
> Steven J Long wrote: |
3 |
>> And that is what we were discussing: possible future coupling between the |
4 |
>> two, which is much easier to do when the sources are part of the |
5 |
>> same package. |
6 |
.. |
7 |
>> OFC you could just assure us that udev will never rely on systemd as a |
8 |
>> design decision. I can understand that systemd might need close |
9 |
>> integration with the underlying udev implementation. |
10 |
> |
11 |
> Nope, can't make that assurance at all. |
12 |
> |
13 |
> Actually, maybe I can make the opposite assurance |
14 |
|
15 |
Well, thanks for being straightforward about it: clearly you're keeping the |
16 |
option of udev requiring systemd open, and in fact want to move toward that. |
17 |
|
18 |
> , let's see what the future brings... :) |
19 |
> |
20 |
Yeah, we'll see :) You have udev working nicely, fulfilling a whole load of |
21 |
use-cases, and now you want to upwardly-couple to er, a service-manager. |
22 |
Running as pid 1, no less, even though it's not necessary. (I predict that |
23 |
latter decision will get reversed in a while, just like a /usr partition |
24 |
went from an anachronism to a grand new design, and xml config formats are |
25 |
no longer talked about; thankfully binary logs got slammed back out the door |
26 |
in-kernel at least[1].) |
27 |
|
28 |
Not build another thing utilising udev and dbus, not even one closely |
29 |
integrated, but upwardly-couple every Linux system to that new userspace |
30 |
project. Good luck with that. |
31 |
|
32 |
steveL. |
33 |
|
34 |
[1] http://lwn.net/Articles/492134/ |
35 |
-- |
36 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |