On Sat, 20 Feb 2021 at 03:23, Olaf Buddenhagen <[email protected]> wrote: > > Hi, > > On Fri, Nov 27, 2020 at 04:41:28PM -0800, Jonathan S. Shapiro wrote: > > > It may surprise you that I agree. *Any* kernel - even one that is trying to > > be "policy free" - makes architectural choices for one reason or another. > > These choices may be good or bad, and they may support your needs or not. > > I'm glad to hear it :-) > > > When L4 and Coyotos were examined, I think the *hope* was that they might > > provide a directly useful base. Coyotos, at the time, didn't provide some > > things that the Hurd wanted. L4 likewise. It's possible that modern L4 > > variants might produce a different result. > > I can't answer that for sure: but for what it's worth, when I recently > glanced over the seL4 documentation (while looking for clarity on some > terminology), my impression was that it wouldn't be a very good fit for > a Hurd-like architecture... Or maybe I'm just lacking imagination ;-) > > (BTW, I didn't get the desired clarity: but perhaps you could chime in? > Is there a good generic term for a capability referencing the receive > end of an IPC port, such as the receive right in Mach?...) >
I don't know if there's a generic term. In Coyotos we have the endpoint. A process can have several endpoints that it is willing to receive from. I don't think we have anything normative about how to have several processes listen to a single endpoint, so the concept doesn't map cleanly to mach receive rights. The seL4 team were smart enough to pilfer plenty of design and terminology from Shap, so they have endpoints too. > > I also believe that there may have been some misunderstanding about L4, > > because it was *never* going to be possible to adopt "the L4 kernel". At > > best, it would be possible to adopt the L4 kernel and then structure some > > core resource management services around it that were designed to support > > the requirements of the Hurd. It was never clear to me if that was how the > > L4 option was approached. > > I do believe that was the plan? The issue was that the cost of the > user-space services that would be needed to properly run a Hurd-like > architecture on top of the original L4 (without kernel capability > support) turned out to be prohibitive... > IME so far, you don't have to implement all of Mach IPC. Mach IPC may be a beautiful mostly-asynchronous channel supporting large, sophisticated message types; but in practice the interfaces that Hurd provides are not that ugly, and neither are those that GNU Mach implements. If there were situations where we'd have to split a Mach message across two or more Coyotos or seL4 messages, we could build that into MIG. Having MIG as almost a level of indirection helps quite a lot. The part that is real work that I've seen so far is that Mach implements virtual memory, and at a very different level to Coyotos or L4. The interface provided to pagers and their clients is very high-level, and is similar to the structure you get from GNU pmap. "This processes address space contains file ld.so from virtual address 0x636f796f746f7300" etc. And then of course it can handle COW and lazy initialisation for you. On the other hand, the interface you get from Coyotos is everything you need to securely build a slightly-abstracted page table by hand. Coyotos includes a not-quite-working implementation of half a COW (c.f. VirtualCopySpace), but it has been a good tutorial for me on how to proceed, and a good reminder of how much work needs to be done. There are definitely other impedance mismatches, but none of them are scary. In the same way the hurd process server does some accounting to make Mach tasks look like Unix processes, some work is needed to combine Coyotos processes and GPTs into a single unix process. Oh, and I really mean that this has been the part that means real work /so far/. I feel like there are still loads of open design questions that the Coyotos design process didn't answer. You can see some of this in the Coyotos Window System abstract. For me, I expect that once I port the hurd filesystem driver to Coyotos, I'll really want to replace much of it, since it feels kind of magical to me and I'd rather give applications more explicit control over caching and other usage patterns, as Viengoos was trying to do. The Single Level Store drivers in CapROS look like they have much more predictable behaviour than an adaptive cache. > > It was a long time ago, now, so my memory is not clear, but I think one of > > the major disconnects was message buffering. Both L4 and Coyotos take the > > position that buffering *in the kernel* is a fundamentally bad idea. In > > most cases, it *reduces* performance and *adds* an opportunity for resource > > denial of service that is inherent in kernel buffering. Both Coyotos and L4 > > take the position that buffering is usually a bad thing to do. But when it > > *must* be done, it should be done by some user-mode application, and should > > be done using storage that the application is obtaining from some properly > > accounted source. Though it arrived too late to be helpful for Hurd, the > > Coyotos "event" and scheduler activation ideas were originally prompted by > > some of the Hurd discussions. > > This is partially true... > > The original Hurd does use Mach's kernel-buffered IPC. However, as far > as I can tell, Neal and Marcus knew from the beginning that kernel > buffering would have to go when porting to any modern kernel. The > question was what to replace it with, in order to still provide the > needed asynchronous functionality... > > In the end, Neal's experimental "Viengoos" kernel used an approach where > the receiver (not the kernel) provides a receive buffer: but the receive > operation can nevertheless happen asynchronously from the receiver's > application threads. (Using some sort of activation-based mechanism -- > though I'm not sure about the details.) > > -antrik- > -- William Leslie Q: What is your boss's password? A: "Authentication", clearly Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.
