| 1 |
> On Feb 17, 2016, at 7:58 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> On Wed, 17 Feb 2016 07:53:22 -0500 |
| 4 |
> Richard Yao <ryao@g.o> wrote: |
| 5 |
> |
| 6 |
>>> On Feb 17, 2016, at 7:43 AM, Michał Górny <mgorny@g.o> wrote: |
| 7 |
>>> |
| 8 |
>>> On Tue, 16 Feb 2016 23:41:33 +0100 |
| 9 |
>>> Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote: |
| 10 |
>>> |
| 11 |
>>>> Alexis Ballier schrieb: |
| 12 |
>>>>>>> If it's just that, it's not limited to udev, but anything using |
| 13 |
>>>>>>> kdbus/bus1, and would mean openrc/${favorite init system} will have |
| 14 |
>>>>>>> to do the same thing anyway. But again, almost 2 years is extremely |
| 15 |
>>>>>>> old considering all the flux that has been around kbus. |
| 16 |
>>>>>> |
| 17 |
>>>>>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel |
| 18 |
>>>>>> IPC system comes next. |
| 19 |
>>>>> |
| 20 |
>>>>> Well, as Lennart wrote it, kbus would have needed some initialisation. |
| 21 |
>>>>> Just like we have a dbus init script, openrc would have a kdbus one. |
| 22 |
>>>>> |
| 23 |
>>>>>> But if upstream udev makes use of the systemd |
| 24 |
>>>>>> userspace interface to the kernel IPC system, then OpenRC would have |
| 25 |
>>>>>> to implement the same interface in order to have working udev. |
| 26 |
>>>>> |
| 27 |
>>>>> As I understand it, a kernel IPC doesn't need systemd to work. udev |
| 28 |
>>>>> might use wrappers from libsystemd, or libbus1, just like we have |
| 29 |
>>>>> programs using libv4l or libbluetooth currently. |
| 30 |
>>>> |
| 31 |
>>>> In a follow-up, upstream wrote about how you should only run udev together |
| 32 |
>>>> with systemd, and if you don't want to do that (spelling as in original): |
| 33 |
>>>> |
| 34 |
>>>> "we will not support the udev-on-netlink case anymore. I see three options: |
| 35 |
>>>> a) fork things, b) live with systemd, c) if hate systemd that much, but |
| 36 |
>>>> love udev so much, then implement an alternative userspace for kdbus to |
| 37 |
>>>> do initialiuzation/policy/activation." |
| 38 |
>>>> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html |
| 39 |
>>>> |
| 40 |
>>>> So it seems a bit more than only initialization is needed. |
| 41 |
>>> |
| 42 |
>>> You're missing the third option which is a sane option, and jump |
| 43 |
>>> straight to pitchforks. |
| 44 |
>>> |
| 45 |
>>> As I see it, *if* this becomes a necessity, we're quite like are going |
| 46 |
>>> to provide KDBUS parts of systemd the way we provide udev parts right |
| 47 |
>>> now. After all, libsystemd-bus will be useful to more applications. |
| 48 |
>>> |
| 49 |
>>> Of course, someone may want to fork that into libebus just for the sake |
| 50 |
>>> of renaming. |
| 51 |
>>> |
| 52 |
>>> And after all, as it has already been noted, there are people |
| 53 |
>>> interested in maintaining non-systemd userspace for KDBUS. Which is |
| 54 |
>>> kinda the obvious choice, unlike forking something. |
| 55 |
>> |
| 56 |
>> kdbus is dead. It is fatally flawed and Greg is no longer trying to get it merged as he is not updating his branch for newer kernel versions. If I recall correctly, kdbus was also removed from Fedora and has no distribution backing it anymore. |
| 57 |
> |
| 58 |
> Then... why are we even discussing this? |
| 59 |
|
| 60 |
I have no idea why we are even discussing the choice of default for virtual/udev to have subdiscussions about kdbus. Practically everyone on the list thinks eudev is the best choice. From the perspective of the Linux community going forward through docker, eudev is the only sensible choice for a udev-based system for those that want to use the same code everyone else uses. |
| 61 |
|
| 62 |
All arguments about systemd are akin to arguments about how Windows 10 is the next thing in desktops in a world dominated by POSIX through iOS and Android. Coincidentally, neither use systemd. |
Archives