On Wed, 24 Feb 2021 at 03:22, Olaf Buddenhagen <[email protected]> wrote: > > 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 :-) >
Yes, but it's maybe not so clear. An endpoint is the name for the entity in the system for receiving messages and it is configured using an endpoint capability, enabling you to listen on it. The sender instead has an entry capability (although the object it names is also the endpoint). > > > 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...) > Oh. I'm not sure of what that cost might have been, then. Do you remember? > > 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... > I am still hopeful that someone will figure out how to do async right at some point. The seL4 people haven't figured it out, and I've got three different approaches, all with their own serious drawbacks. > > 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...) > Not that this has anything to do with whether someone can port The HURD to an L4 or Coyotos like architecture: I am as convinced today as I was back when Marcus first ranted about ownership and shopping trolleys that he was mostly wrong (12 years ago? before I kept logs). If you're running an operating system locally, you absolutely want (and already technically have) the ability to subvert any software protections, including factories. You may as well reify this as a capability so that programs you nominate can peek into attempts at mutually secure collaboration. If the computer you're operating on is some sort of shared hosting situation, you probably want your provider to be audited /not/ to be able to peek inside anything that you created using a factory. Real security actually improves user freedom; more so given just how broad the sort of attacks that are not only possible but are exercised are becoming. > > 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... > Yes, not really, and also not what I was talking about. Firstly, the tricky thing with accounting memory in Unix. Let's assume you want to do hard memory accounting as a first pass. This means a process can't go and map memory that you don't have swap for. If a process attempts to map a copy and the pages aren't available in memory or swap, it will fail in the call to map. Now you've got reliable failures on memory limit problems. This may break some applications, but at least you get sensible error messages so that you can fix the application or free memory. The problem, however, is fork(). Fork is tricky because how much memory do you account to the child? If you need to account everything mapped COW into the address space of the parent, then large processes won't be able to start other processes, even if those children would immediately exec. If you don't account everything COW in the parent, then you have a situation where a process can run out of memory without explicitly allocating it. What I would personally like is precise accounting by default (as in the SLS), and lazy accounting on fork by request. That way I could still run firefox when needed, yet have a system that is much more stable under memory load than anything traditional. -- Also: running the hurd directly out of the SLS means I avoid the need to bootstrap it the same way we do on Mach: dynamic linker needs the filesystem, so filesystem must be statically linked. TBF all my programs so far are statically linked, but having a really simple filesystem like SLS to strap from instead of ext2 is very convenient. -- 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.
