| |||||||||||||
|
| |||||||||||||
If Mach was the failure point, why?If Mach was the failure point, why?Posted Jul 1, 2010 16:03 UTC (Thu) by patrick_g (subscriber, #44470)In reply to: If Mach was the failure point, why? by neal Parent article: GNU HURD: Altered visions and lost promise (The H)
>>>Regarding resource management, a problem which becomes particularly acute in highly-decomposed systems (such as multi-server systems), is the difficulty in coordinating resource use.
(Log in to post comments)
If Mach was the failure point, why? Posted Jul 1, 2010 17:20 UTC (Thu) by pboddie (guest, #50784) [Link] Here's an interesting attempt to overcome such problems: Moreover, Nemesis has been designed such that these Quality of Service guarantees are meaningful: In a microkernel environment, an application is typically implemented by a number of processes, most of which are servers performing work on behalf of more than one client. This leads to enormous difficulty in accounting for resource usage. In a kernel-based system, multimedia applications spend most of their time in the kernel, leading to similar problems. (From the Nemesis documentation.) That was ten years ago now, however, and I guess nobody picked it up when the funding ran out.
If Mach was the failure point, why? Posted Jul 2, 2010 8:17 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
> Now, the real problem with split access spaces is not the performance issue (which does exist), but the much higher complexity issue.
Compare, for interest, with gist of The Art of Unix Programming (http://www.faqs.org/docs/artu/).
It is also interesting that many parts of a Linux system which perform a kernel-like function (X11, PulseAudio) are in user space servers. Although if that proves anything it is that there is no one-size-fits-all here.
If Mach was the failure point, why? Posted Jul 2, 2010 12:08 UTC (Fri) by nix (subscriber, #2304) [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.
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.
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 whateverI 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.
|
|
||||||||||||