If Mach was the failure point, why? [LWN.net]

If Mach was the failure point, why?

Posted Jul 2, 2010 18:26 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

> Yeah, but quite a lot of X11's kernel-like function has finally moved into the kernel where it belongs :) I'm not sure the protocol handling really belongs in kernel space, but the hardware access surely always did. And now it's there.

I must admit that I've always rather liked the micro-kernel idea, but yes, having minimal hardware drivers in the kernel, with enough extra logic for similar devices to present similar interfaces to user space (although I'm not sure I would consider e.g. a five-to-ten year old network card similar to a modern one in that respect) also always seemed like a clean separation. I do wonder how it would be if things like the TCP/IP stack, or at least the upper layers, were in user space. Not sure if I could get many kernel people to wonder about that sort of thing though...

If Mach was the failure point, why?

Posted Jul 4, 2010 19:18 UTC (Sun) by nix (subscriber, #2304) [Link]

Wasn't pushing the TCP/IP layer to userspace the point of the 'channels' stuff?

(not sure how you'd do advanced routing or firewalling that way, though.)

If Mach was the failure point, why?

Posted Jul 5, 2010 21:30 UTC (Mon) by michaeljt (subscriber, #39183) [Link]

>Wasn't pushing the TCP/IP layer to userspace the point of the 'channels' stuff?
>(not sure how you'd do advanced routing or firewalling that way, though.)

Your mentioning that gave me an impulse to read over the channels stuff again, and it is pretty neat stuff, even if it seems to have hit a few snags (any idea what happened to it? I presume that at least some of the ideas got taken up). I must admit that what I had in mind was just the idle thoughts of someone not particularly knowledgeable about networking, and I certainly hadn't given thought to the details of CPU core cache and things.

Just for the fun of it I will try to give those thoughts a shape though.

* an in-kernel network device driver (probably with a /dev entry) which can accept data to transmit and return data, as naked ethernet frames, or raw TCP data, or whatever the card can do in hardware.
* a userspace server to multiplex the driver which can accept socket connections or whatever from clients and can accept and return data as ethernet frames, ip packages or whatever, but can tell the clients what it can handle most efficiently. It will do whatever checks are needed on outbound data to be sure that the client is allowed to send what it is sending, and will do whatever checks are needed on the inbound data to know where to send it. That is likely to put an end to keeping things on a single core unless the checks can be offloaded to the hardware.
* hopefully some optimisation of the kernels socket primitives so that as much as possible of the data copying accross sockets can be collapsed into single operations, preferable DMA between card and the final client. Should be doable for e.g. outbound TCP data with clever cards, perhaps even for inbound data if the card can buffer it for a short time and give the server just enough information to know where to forward it to.

I'm sure that there are millions of holes in that logic, just for a start what happens when in-kernel clients need to send network data (if someone pushing a network stack into userspace really cares about in-kernel clients). Feel free to poke a few more if you like...

If Mach was the failure point, why?

Posted Jul 7, 2010 11:36 UTC (Wed) by nix (subscriber, #2304) [Link]

a userspace server to multiplex the driver which can accept socket connections or whatever from clients and can accept and return data as ethernet frames, ip packages or whatever

I thought the whole point of VJ tunnels was to avoid copies? Possibly we want a scheme where the kernel hands you raw IP packets which may be zero-copied. If you have NAT or some kinds of firewalling in the way obviously they would not be, but sometimes they would, and when they were you could gain the speed benefits. This doesn't stop the kernel inspecting the raw IP packets and sending them to different clients or anything like that, so I don't think you need a userspace multiplexor at all.