[qwertyuiop924]

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

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.

[qwertyuiop924]

Thanks. Sorry. I'm still not convinced that bus1 is a good idea, but at least that's been cleared up.

[the_why_of_y]

> ... and includes a permissions system ...

The whole point of capability based security is that there is no permission system, because permissions are implicit in the capabilities. So this is much simpler than e.g. SysV message queues.