Hi, On Sat, Feb 20, 2021 at 12:07:27PM +1100, William ML Leslie wrote: > On Sat, 20 Feb 2021 at 03:23, Olaf Buddenhagen <[email protected]> > wrote:
> > 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. Yeah, I was thinking of "endpoint"... Indeed that's how I stumbled upon the seL4 docs! > The seL4 team were smart enough to pilfer plenty of design and > terminology from Shap, so they have endpoints too. Here's the thing: it appears that in seL4, an "endpoint" is the IPC port itself -- with an endpoint capability referencing either the sender or the receiver end. (Or both.) However, if in Coyotos "endpoint" clearly denotes the receiver end, I guess that's good enough for me in terms of precedent :-) > > 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. That's never been the plan, to the best of my knowledge... That would remove most of the point of moving away from Mach. The idea was just to implement *some* sort of capability-based IPC. (And some sort of asynchronous communication ability...) > 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. The message typing is really the least important aspect of Mach IPC IMHO... What makes it pretty convenient for writing interfaces with little abstraction, is the way in handles senders/receivers, notification etc., in a way that feels very natural in most situations. Unfortunately, that pretty much depends on the kernel buffering, as far as I can tell -- so it's not really a good design in practice... > There are definitely other impedance mismatches, but none of them are > scary. In my understanding, aside from the async communication question, the main point of contention was the use of protected constructors: Marcus ultimately concluded that they don't align with the GNU philosophy -- proposing a strictly hierarchical structure instead. (Much like what Genode emerged with at around the same time, as I understand it...) > 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. That's a no-brainer really: Neal came up with the concept specifically to address the resource management issues with Hurd/Mach... > The Single Level Store drivers in CapROS look like they have much more > predictable behaviour than an adaptive cache. Excuse my ignorance: but isn't the single level store concept closely related to orthogonal persistence? That would be a controversial choice for a Hurd-like system, to put it mildly... -antrik-
