It's Been A Quiet Year-End For BUS1, The Proposed In-Kernel IPC For Linux

[tomegun]

they are unable to develop this software.

Huh? Context? What makes you say that?

[tomegun]

Yes, please do. Instead just complaining, please provide useful information about the topic too. As I always seen, Linux developers needs to be smarter at PR.

I did not intend to complain, just made an offer.

[tomegun]

So can you please fill us in. What's the status? What is the expected target for inclusion? What is the idea with that bus2 branch?

The current status is that one RFC was sent, a presentation was made at ksummit/LPC and we received very helpful and constructive feedback from the kernel community. We will incorporate their suggestions (though there will not really be any major changes) and post another RFC sometime early next year. Depending on the feedback to that we will make a decision as to when we ask for upstream inclusion (how many rounds of RFCs we feel we need), but there is no rush. What matters is to gather feedback and make sure we have the best codebase we can, then it will go upstream when it is ready.

The bus2 branch was just a development branch that has since been merged back into the master branch. It was called bus2 for the simple reason that we would have bus1.ko being the module from the master branch and bus2.ko being the module from the development branch, so they could both be used at the same time for testing. Anyway, that is all gone now, there is not going to be a "bus2" if hat is the impression people got.

[tomegun]

BTW, are there any recordings available from Linux Plumbers 2016?

Sadly no recordings.

[tomegun]

Is the motivation behind this to evolve linux to a microkernel?

Not really no. The motivation is for use by userspace, to make it possible to make userspace components more modular (more micro-kernel-like if you wish). It could in principle also be used to move stuff from the kernel to userspace, but that is not our motivation or our focus personally.

[tomegun]

In short:
bus2 is supposed to be high-level cross-platform API compatible with Windows Data Copy, but because of licensing issues bus2 is supposed to be taken over by Microsoft and licensed in the Linux kernel under a permissive license.

If bus2 fails, there's still plans to ship bus1 with the Linux kernel.

In case this was not obvious to everyone: this is bullshit. Please cut it out.

[starshipeleven]

Is the motivation behind this to evolve linux to a microkernel?

microkernel = Rust in kernel = over Torvalds dead body.

[cl333r]

microkernel = Rust in kernel = over Torvalds dead body.

I've never seen anyone mentioning any serious reason for a microkernel - like "I can't do XYZ, it's impossible with Linux, but if it was a microkernel then I could do it this or that way".

[liam]

I've never seen anyone mentioning any serious reason for a microkernel - like "I can't do XYZ, it's impossible with Linux, but if it was a microkernel then I could do it this or that way".

Really? I can name some: hard real-time responses, transparent failure and reinsertion of failed servers (modules....like the fs, for instance), seamless upgrades of every server without turning the machine off, sil4 reliability, MUCH easier to verify for security issues as it is designed to be composed (very UNIXy).
Modern (gen3 or 4) ukernels are far faster than the early ones.
As I see it two sorts of operating systems stories be in use: ones with ukernels and ones that don't recognize the distinction between kernel and user space (library os).

[liam]

Not really no. The motivation is for use by userspace, to make it possible to make userspace components more modular (more micro-kernel-like if you wish). It could in principle also be used to move stuff from the kernel to userspace, but that is not our motivation or our focus personally.

Well, in that vein, have you folks been benchmarking this?
What kind of latency (delta between request and response) are you seeing relative to things like mmap, netlink, ashmem/binder?
How well does it scale? Could we implement, say, a touchscreen driver in userspace?

On a side note, this could make it easier to properly implement aio.