3 ms·

What's high-level about bus1? This has nothing to do with systemd, and very little (apart from history) to do with kdbus. As to portability, this is a linux ke

by tomegun 10y ago

What's high-level about bus1? This has nothing to do with systemd, and very little (apart from history) to do with kdbus. As to portability, this is a linux kernel module, but there is nothing really inherent to linux about it, so porting it to another kernel should not be a lot of work if that is interesting to anyone.

qwertyuiop924 10y ago
What's high level? They're providing a message bus. That's not an IPC primitive. That's very high-level. As for systemd, I gathered there was a connection to kdbus, which was Lennart's baby. Thusly, I gathered it needed init to cooperate, the same way kdbus did, and any non-bus1-aware init just wouldn't work with apps that used bus1. As for portability, what other OS will implement this muck? None of them. It's portable the same way systemd is: "apps that depend on us are portable, so long as every os copies all our stuff, and re-implements all our APIs" Forcing other OS's to implement your stuff isn't portability.
- the_why_of_y 10y ago
  None of QNX IPC, Mach IPC, Minix3 IPC, Solaris Doors, NT LPC or Android Binder is portable, and all of them are used by low-level user-space on their respective platform. But if Linux developers add a new IPC mechanism for similar purposes, it must be useless "muck"?
  - qwertyuiop924 10y ago
    NT doesn't have to worry about compat. Neither do Android apps. QNX, Mach, and Minix3 are microkernels, and that IPC isn't used by high-level userland in the UNIX compatible systems. Doors is something I have similar objections to. But if bus1 is a successor to kdbus, it's not intended to be used by low-level userland, it's built for highlevel userspace. Like systemd, this is trying to coax high-level userland to be incompatible with other unixes. The fact that no unixes other than the originating one, if the orginator was a unix, has picked up any of these systems speaks volumes about why you shouldn't use it in highlevel userland.
- tomegun 10y ago
  Please look at the code. bus1 is no more high-level than UDS. You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc. bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic. When I said that bus1 should be reasonably portable, I meant exactly that: the code of bus1 itself should be easy to port to other OSs. Whether apps that use bus1 are easy to port to systems without bus1 depends on how what they do and what is available on the other systems in question...
  - qwertyuiop924 10y ago
    Well, that's not what you said, but portability, I'll accept. The fact that Bus1 doesn't need init cooperation is good. However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than DBUS. As for kdbus not being Lennart's baby, and that I should look at who wrote the code, I did. I direct you to https://lwn.net/Articles/580194/ https://lwn.net/Articles/580194/, where Lennart not only takes credit for KDBus, but also says it's application-level, implying it is intended to be used in high-level userland. High-level abstractions for applications don't belong in the kernel.
    - tomegun 10y ago
      There is not really a permission system in bus1 any more than fd passing is a permission system. What bus1 gives you is the primitives to build a permission system though. There is no sealing in bus1. The payload of a bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish. kdbus is higher level than bus1, don't confuse the two. kdbus is still not at the application level though, there would have to be a userspace component inbetween. High-level abstractions for applications don't belong in the kernel, I agree. But that is a strawman, bus1 is not doing that at all.

by tomegun 10y ago

qwertyuiop924 10y ago

What's high level? They're providing a message bus. That's not an IPC primitive. That's very high-level. As for systemd, I gathered there was a connection to kdbus, which was Lennart's baby. Thusly, I gathered it needed init to cooperate, the same way kdbus did, and any non-bus1-aware init just wouldn't work with apps that used bus1. As for portability, what other OS will implement this muck? None of them. It's portable the same way systemd is: "apps that depend on us are portable, so long as every os copies all our stuff, and re-implements all our APIs" Forcing other OS's to implement your stuff isn't portability.

the_why_of_y 10y ago
None of QNX IPC, Mach IPC, Minix3 IPC, Solaris Doors, NT LPC or Android Binder is portable, and all of them are used by low-level user-space on their respective platform. But if Linux developers add a new IPC mechanism for similar purposes, it must be useless "muck"?
- qwertyuiop924 10y ago
  NT doesn't have to worry about compat. Neither do Android apps. QNX, Mach, and Minix3 are microkernels, and that IPC isn't used by high-level userland in the UNIX compatible systems. Doors is something I have similar objections to. But if bus1 is a successor to kdbus, it's not intended to be used by low-level userland, it's built for highlevel userspace. Like systemd, this is trying to coax high-level userland to be incompatible with other unixes. The fact that no unixes other than the originating one, if the orginator was a unix, has picked up any of these systems speaks volumes about why you shouldn't use it in highlevel userland.
tomegun 10y ago
Please look at the code. bus1 is no more high-level than UDS. You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc. bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic. When I said that bus1 should be reasonably portable, I meant exactly that: the code of bus1 itself should be easy to port to other OSs. Whether apps that use bus1 are easy to port to systems without bus1 depends on how what they do and what is available on the other systems in question...
- qwertyuiop924 10y ago
  Well, that's not what you said, but portability, I'll accept. The fact that Bus1 doesn't need init cooperation is good. However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than DBUS. As for kdbus not being Lennart's baby, and that I should look at who wrote the code, I did. I direct you to https://lwn.net/Articles/580194/ https://lwn.net/Articles/580194/, where Lennart not only takes credit for KDBus, but also says it's application-level, implying it is intended to be used in high-level userland. High-level abstractions for applications don't belong in the kernel.
  - tomegun 10y ago
    There is not really a permission system in bus1 any more than fd passing is a permission system. What bus1 gives you is the primitives to build a permission system though. There is no sealing in bus1. The payload of a bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish. kdbus is higher level than bus1, don't confuse the two. kdbus is still not at the application level though, there would have to be a userspace component inbetween. High-level abstractions for applications don't belong in the kernel, I agree. But that is a strawman, bus1 is not doing that at all.