Describing coyotos: processes

[Jonathan S. Shapiro]

As most of you [vaguely] know, I've been working on a book describing Coyotos. At this stage I'm still getting the kernel description organized. I find that I'm tripping over something repeatedly, and I'd like to get the sense of the room.

Nearly every Coyotos kernel object has a direct hardware analogue: pages are pages, GPTs are enhanced page tables, and so forth. If we allow for the prospect of capability-aware hardware, I'd add capability pages to the list.

There are two exceptions to this: processes and endpoints. Descriptively, endpoints are more or less noise. But the term "process" has a lot of contextual weight that has been getting in my way as I write. Early processes essentially model processors with minimal baggage. Later processes are resource containers with execution peformed by threads and descriptor tables added in lieu of first class descriptor support in address spaces and registers. And signals. And so forth.

One of the long-term descriptive challenges for the Coyotos kernel has been: is it an OS kernel or is it more helpful to think of it as a virtual machine manager for a software-enhanced hardware machine? The current lexicon straddles this line in a fairly awkward way, and (at least to my mind) has done so since 1991.

As I've thougt about the CHERI work and applicability to Coyotos, and the possibility of FPGA support, it belatedly occurred to me that "process" may be the wrong name for that Coyotos object, and perhaps the right name for that abstraction is actually "processor".

Emotional writing entanglement aside, this feels to me like it fits what's going on. There's a lot of semantics that goes with "process as container" that the Coyotos kernel just doesn't have. If you want that kind of process, God bless, and that's what process fault handlers are for.

So my question for the room: how do people feel about renaming "process" to "processor"? I'm inclined to try it provisionally in the document and see if it makes things better.

Thoughts?

Jonathan

[Alan Karp]

Processor makes me think of the CPU.  I'm likely to ask, "What's the instruction set?"

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/e9aefb6a-8246-462a-b7fb-3987cb68c551n%40googlegroups.com.

[Matt Rice]

On Thu, Dec 11, 2025 at 4:41 AM Jonathan S. Shapiro
<jonathan....@gmail.com> wrote:
>
> As most of you [vaguely] know, I've been working on a book describing Coyotos. At this stage I'm still getting the kernel description organized. I find that I'm tripping over something repeatedly, and I'd like to get the sense of the room.
>
> Nearly every Coyotos kernel object has a direct hardware analogue: pages are pages, GPTs are enhanced page tables, and so forth. If we allow for the prospect of capability-aware hardware, I'd add capability pages to the list.
>
> There are two exceptions to this: processes and endpoints. Descriptively, endpoints are more or less noise. But the term "process" has a lot of contextual weight that has been getting in my way as I write. Early processes essentially model processors with minimal baggage. Later processes are resource containers with execution peformed by threads and descriptor tables added in lieu of first class descriptor support in address spaces and registers. And signals. And so forth.
>

I guess I was also wondering about scheduling queues,

> One of the long-term descriptive challenges for the Coyotos kernel has been: is it an OS kernel or is it more helpful to think of it as a virtual machine manager for a software-enhanced hardware machine? The current lexicon straddles this line in a fairly awkward way, and (at least to my mind) has done so since 1991.
>
> As I've thougt about the CHERI work and applicability to Coyotos, and the possibility of FPGA support, it belatedly occurred to me that "process" may be the wrong name for that Coyotos object, and perhaps the right name for that abstraction is actually "processor".
>
> Emotional writing entanglement aside, this feels to me like it fits what's going on. There's a lot of semantics that goes with "process as container" that the Coyotos kernel just doesn't have. If you want that kind of process, God bless, and that's what process fault handlers are for.
>
>
> So my question for the room: how do people feel about renaming "process" to "processor"? I'm inclined to try it provisionally in the document and see if it makes things better.
>

I don't know how I feel about it, my first thought was that an actual
hardware processor/cpu has things like
protection rings which to me resembles kernel itself more. It feels
like a strained analogy, but maybe try it.

> Thoughts?

I haven't thought too extensively about it, but I wonder if dividing
things into "resources", and forms of "resource accounting" or
bookkeeping wouldn't be a way to explain this. In particular,
resources always seem like they towards having a direct hardware
analog, then explain the others as providing some accounting/ownership
of resources themselves.

Like I said I haven't considered it too carefully, it's just the first
reaction I had for some bifurcation that could potentially make some
sense.

[William ML Leslie]

On Thu, 11 Dec 2025 at 14:41, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

So my question for the room: how do people feel about renaming "process" to "processor"? I'm inclined to try it provisionally in the document and see if it makes things better.

My favourite didactic approach to explaining the 5 Coyotos kernel objects has been that each one leads to the next.  Once you've explained pages, cappages are easy to explain as they are a page that allows you to have protected references; and once you have those two, GPTs are a natural way to combine them into a linear address space, and then you need processes to operate within an address space, and then you need endpoints to mediate access to processes, and look, you've got all five objects covered.

I don't know that anyone reading a history of these systems would need any additional explanation as to what a thread of control is.

 

--

William ML Leslie

[Matt Rice]

So, after thinking about it overnight, I wonder if part of the issue
here is that processes don't actually
exhibit the traditional hardware resource ownership model that other
resources do.
In particular, that ownership over a processor is shared with the
processes "owning it" only for a period...
At that point the notion of resource and bookkeeping comes under
tension since it kind of acts like both...
*shrug* I see now processor as an attempt to make it fit more neatly
into the resource bin.

[Jonathan S. Shapiro]

On Wed, Dec 10, 2025 at 8:48 PM Alan Karp <alan...@gmail.com> wrote:

Processor makes me think of the CPU.

Yes. And that's pretty exactly the right intuition.

 

I'm likely to ask, "What's the instruction set?"

Yup. And that's also a good intuition. Coyotos and EROS don't have system calls in the traditional style. They have load/store instructions for capabilities and an "invoke capability" instruction.

Jonathan 

 

[Jonathan S. Shapiro]

On Wed, Dec 10, 2025 at 9:24 PM Matt Rice <rat...@gmail.com> wrote:

> There are two exceptions to this: processes and endpoints.

I guess I was also wondering about scheduling queues,

That's fair.

 

> So my question for the room: how do people feel about renaming "process" to "processor"?

I don't know how I feel about it, my first thought was that an actual
hardware processor/cpu has things like
protection rings which to me resembles kernel itself more. It feels
like a strained analogy, but maybe try it.

Rings are actually how we got in trouble when virtualization hit. The better processor designs have only user and supervisor mode, and are designed to be virtualizable without further complications. For Intel, it was already too late when the issue arose.

Every time I try to write down how "processes" work in Coyotos, I find myself getting hung up on the fact that processes in every other system are resource containers. What we have called "process" in EROS is basically a register set. The notable exception is the scheduling slot. The conundrum didn't arise when I wrote about KeyKOS, because they were called "domains". That removed the baggage of the conventional definition of "process".

Simultaneously, as you know, I've been catching up on CHERI and looking at FPGAs. I can totally imagine taking a Coyotos process and implementing it as an extended RISC-V or ARM processor soft core on an FPGA. This isn't an accident - Norm and I talked about domains all the time.

That said, it's more like a virtual core/processor than a hardware processor. Or I suppose it could be called CCPU (Capability CPU) or we could revert back to "domain". I personally don't care for "domain" for two reasons:

1. It doesn't appeal to any of the "this thing is a lot like an extended CPU core" intuitions, and
2. The actual protection domain includes more things than its execution engine.

Jonathan

[Jonathan S. Shapiro]

On Wed, Dec 10, 2025 at 9:53 PM William ML Leslie <william.l...@gmail.com> wrote:

My favourite didactic approach to explaining the 5 Coyotos kernel objects has been that each one leads to the next.

Yes. There are a couple of possible orderings, but I agree that this is a pretty straightforward approach and seems to work well.

 

...and then you need processes to operate within an address space

When explaining to people who are coming from UNIX or Windows processes, this can lead to trouble. There seem to be two points of confusion. The first is that UNIX/Windows processes are resource containers. Many of those resources are "owned", in the sense that if the process is torn down then those resources are torn down. The second is that address spaces in Coyotos are first class, where they are not in conventional systems.

Yes, you can talk your way through that, but the background intuitions drawn from other systems tend to pop up every once in a while to create confusion. 

 

I don't know that anyone reading a history of these systems would need any additional explanation as to what a thread of control is.

I think that's probably right. But the audience for the Coyotos book. is people coming from UNIX or Windows.

Jonathan

[Matt Rice]

On Fri, Dec 12, 2025 at 2:34 AM Jonathan S. Shapiro
<jonathan....@gmail.com> wrote:
>
> On Wed, Dec 10, 2025 at 9:24 PM Matt Rice <rat...@gmail.com> wrote:
>>
>> > There are two exceptions to this: processes and endpoints.
>>
>> I guess I was also wondering about scheduling queues,
>
>
> That's fair.
>
>>
>> > So my question for the room: how do people feel about renaming "process" to "processor"?
>>
>> I don't know how I feel about it, my first thought was that an actual
>> hardware processor/cpu has things like
>> protection rings which to me resembles kernel itself more. It feels
>> like a strained analogy, but maybe try it.
>
>
> Rings are actually how we got in trouble when virtualization hit. The better processor designs have only user and supervisor mode, and are designed to be virtualizable without further complications. For Intel, it was already too late when the issue arose.
>
> Every time I try to write down how "processes" work in Coyotos, I find myself getting hung up on the fact that processes in every other system are resource containers.

Sure, I guess the thought I was trying to get across is that if people
are getting hung up on the preconceived idea of what a process is,
It's likely people will also bring along their specific details of the
CPU architectures they are familiar with, and try to relate those to
processes.
Rings being just an example of arbitrary details, that it isn't clear
how they would apply to processes.

> What we have called "process" in EROS is basically a register set. The notable exception is the scheduling slot. The conundrum didn't arise when I wrote about KeyKOS, because they were called "domains". That removed the baggage of the conventional definition of "process".
>
> Simultaneously, as you know, I've been catching up on CHERI and looking at FPGAs. I can totally imagine taking a Coyotos process and implementing it as an extended RISC-V or ARM processor soft core on an FPGA. This isn't an accident - Norm and I talked about domains all the time.
>
> That said, it's more like a virtual core/processor than a hardware processor. Or I suppose it could be called CCPU (Capability CPU) or we could revert back to "domain". I personally don't care for "domain" for two reasons:
>

Indeed I had thought of and almost mentioned referring to it as a
"virtual core/processor", but using the virtual term I was worried
would be confused with
virtual machines/virtualization. The term idealized core/processor
comes to mind, as an alternative without the virtualization baggage.
But I do think that virtual/idealized some qualifier of that sort
would help avoid these unwanted comparisons to arch specific details.

[Bakul Shah]

On Dec 11, 2025, at 6:40 PM, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

When explaining to people who are coming from UNIX or Windows processes, this can lead to trouble. There seem to be two points of confusion. The first is that UNIX/Windows processes are resource containers. Many of those resources are "owned", in the sense that if the process is torn down then those resources are torn down. The second is that address spaces in Coyotos are first class, where they are not in conventional systems.

Not sure what you mean by "processes are resource containers" or "resources are owned" (by a process). A file descriptor is an index into its file descriptor table, which points to an (open) file table entry, which points to an inode and things are garbage collected if their refcounts drop to zero when a process dies. One can think of a file descriptor as sort of a capability.

[William ML Leslie]

In UNIX/Windows, a Process contains threads and pages that make up an address space.  The Process "owns" these things, in the sense that when the process goes away, these other things also cease to exist.

In Coyotos, a Process has a reference to an object that serves as its address space.  Several Processes can share an address space, and you can change the address space that a Process operates in.

--

William ML Leslie

[Jonathan S. Shapiro]

On Thu, Dec 11, 2025 at 7:59 PM 'Bakul Shah' via cap-talk <cap-...@googlegroups.com> wrote:

Not sure what you mean by "processes are resource containers" or "resources are owned" (by a process). A file descriptor is an index into its file descriptor table, which points to an (open) file table entry, which points to an inode and things are garbage collected if their refcounts drop to zero when a process dies. One can think of a file descriptor as sort of a capability.

Yes. But the descriptor table and the address space are resources contained by a process. Also threads. They are not first class; they are things contained by the process.

Hope that clarifies.

Jonathan

[William ML Leslie]

On Fri, 12 Dec 2025 at 14:25, William ML Leslie <william.l...@gmail.com> wrote:

In UNIX/Windows, a Process contains threads and pages that make up an address space.  The Process "owns" these things, in the sense that when the process goes away, these other things also cease to exist.

In Coyotos, a Process has a reference to an object that serves as its address space.  Several Processes can share an address space, and you can change the address space that a Process operates in.

So I said "a Process has a reference", but more specifically, whenever the system runs a process, the system uses the capability in its addressSpace field to configure and set up the mappings (page tables etc) the current process will run in.  It uses the capability in the addressSpace field to resolve any page faults or other kinds of memory lookups while the process is executing.

A wild concept is that if you use a Factory to build your process, it starts out with a single, read-only page as its addressSpace.  The page has all of the code it needs to reach out and either allocate itself a space handler or allocate itself a C stack and copy of the image it will switch to.  That little bit of bootstrap assembler code is adorable.

--

William ML Leslie

[Ben Laurie]

On Thu, 11 Dec 2025 at 04:41, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

As most of you [vaguely] know, I've been working on a book describing Coyotos. At this stage I'm still getting the kernel description organized. I find that I'm tripping over something repeatedly, and I'd like to get the sense of the room.

Nearly every Coyotos kernel object has a direct hardware analogue: pages are pages, GPTs are enhanced page tables, and so forth. If we allow for the prospect of capability-aware hardware, I'd add capability pages to the list.

If you are thinking of CHERI as "capability-aware hardware" it feels a bit odd to think about capability pages. In CHERI *all* pointers are bounded and permissioned regions, and they can be any size (with some rounding for large allocations).

BTW, I'd be happy to join a friam to discuss CHERI if that would be helpful. Or a special meeting just for that (slightly earlier than friam would suit me better).

I might be able to drag Robert Watson along, too.

 

There are two exceptions to this: processes and endpoints. Descriptively, endpoints are more or less noise. But the term "process" has a lot of contextual weight that has been getting in my way as I write. Early processes essentially model processors with minimal baggage. Later processes are resource containers with execution peformed by threads and descriptor tables added in lieu of first class descriptor support in address spaces and registers. And signals. And so forth.

One of the long-term descriptive challenges for the Coyotos kernel has been: is it an OS kernel or is it more helpful to think of it as a virtual machine manager for a software-enhanced hardware machine? The current lexicon straddles this line in a fairly awkward way, and (at least to my mind) has done so since 1991.

As I've thougt about the CHERI work and applicability to Coyotos, and the possibility of FPGA support, it belatedly occurred to me that "process" may be the wrong name for that Coyotos object, and perhaps the right name for that abstraction is actually "processor".

Emotional writing entanglement aside, this feels to me like it fits what's going on. There's a lot of semantics that goes with "process as container" that the Coyotos kernel just doesn't have. If you want that kind of process, God bless, and that's what process fault handlers are for.

So my question for the room: how do people feel about renaming "process" to "processor"? I'm inclined to try it provisionally in the document and see if it makes things better.

Thoughts?

Jonathan

--

[Alan Karp]

On Fri, Dec 12, 2025 at 8:43 AM 'Ben Laurie' via cap-talk <cap-...@googlegroups.com> wrote:

BTW, I'd be happy to join a friam to discuss CHERI if that would be helpful. Or a special meeting just for that (slightly earlier than friam would suit me better).

I might be able to drag Robert Watson along, too.

I'd like that even if it's earlier. 

--------------
Alan Karp

[Valerio Bellizzomi]

Fron Google:

The operating system that refers to processes as "

loci" is Grasshopper. 

Grasshopper is a research operating system specifically designed to support persistent systems, where data and running processes (loci) can move between different "containers" (computational environments or machines). This allows for a unique form of distributed computation and process migration.

[Daira-Emma Hopwood]

On Fri, 12 Dec 2025, 02:34 Jonathan S. Shapiro, <jonathan....@gmail.com> wrote:

Every time I try to write down how "processes" work in Coyotos, I find myself getting hung up on the fact that processes in every other system are resource containers. What we have called "process" in EROS is basically a register set. The notable exception is the scheduling slot. The conundrum didn't arise when I wrote about KeyKOS, because they were called "domains". That removed the baggage of the conventional definition of "process".

"Domain" seems like a good name to me. "Task" is another possibility, although that has some possibly unintended baggage from languages that use that term.

That said, it's more like a virtual core/processor than a hardware processor.

I would expect something that is called a processor to be pretty much as complicated as a conventional processor (even if it is virtualized), which might not be the intuition you want to convey.

Or I suppose it could be called CCPU (Capability CPU) or we could revert back to "domain". I personally don't care for "domain" for two reasons:

1. It doesn't appeal to any of the "this thing is a lot like an extended CPU core" intuitions, and
2. The actual protection domain includes more things than its execution engine.

How about "engine", then?

-- 

Daira-Emma Hopwood

[Daira-Emma Hopwood]

On Fri, 12 Dec 2025, 16:43 'Ben Laurie' via cap-talk, <cap-...@googlegroups.com> wrote:

BTW, I'd be happy to join a friam to discuss CHERI if that would be helpful. Or a special meeting just for that (slightly earlier than friam would suit me better).

I might be able to drag Robert Watson along, too.

Incidentally, I plan to be in San Jose from 22nd December to 6th January. Are physical friam meetings still held in Mountain View? If so, it's only a stone's throw away and I'd love to catch up with you all in person. It's been way too long! Maybe on Friday 2nd January?

Discussing CHERI at that meeting would be the icing on top 🥰

-- 

Daira-Emma Hopwood

[Jonathan S. Shapiro]

On Sun, Dec 14, 2025 at 1:58 PM 'Daira-Emma Hopwood' via cap-talk <cap-...@googlegroups.com> wrote:

"Domain" seems like a good name to me. "Task" is another possibility, although that has some possibly unintended baggage from languages that use that term.

I ended up coming to the same conclusion, and it got me completely unblocked on the writing. The problem with "processor" is that there are places where it becomes hard to keep track of which thing is the software processor and which thing is the hardware processor.

Along the way I figured out why "process" was bugging me. Partly, as a I said previously, a "process" is commonly understood as a container that has some ownership relations to other containers, and that's not how the KeyKOS family thinks about things.

As I got un-stuck, I stumbled into the question of process models. The KeyKOS family is really very agnostic about this - to the extent that it's possible to run "native" domains alongside UNIX processes, each seeing the process abstraction that it expects (which are very different). I wouldn't go so far as to say that Coyotos doesn't have a process model, but it's very low level. In effect, it amounts to "Well, I told you something happened by sending you a message about it. Maybe you should go do something about it, but that's up to you."

For the moment, I'm proceeding with "domain" and things are going pretty well. If we decide to change it later, a simple find and replace should work pretty well. :-)

Jonathan

[Alan Karp]

No more physical meetings since the pandemic.  Only Zoom.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAPa%3DBYJ_oq2kZgmq-1Y4QDwVvB1MJjNRNENWUoD8m5%3DoEp3EFg%40mail.gmail.com.

[Bakul Shah]

[Oops, forgot to hit the send button...]

Thanks, William & Jonathan, for clarifying.

On Dec 11, 2025, at 8:25 PM, William ML Leslie <william.l...@gmail.com> wrote:

On Fri, 12 Dec 2025 at 13:59, 'Bakul Shah' via cap-talk <cap-...@googlegroups.com> wrote:

On Dec 11, 2025, at 6:40 PM, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

When explaining to people who are coming from UNIX or Windows processes, this can lead to trouble. There seem to be two points of confusion. The first is that UNIX/Windows processes are resource containers. Many of those resources are "owned", in the sense that if the process is torn down then those resources are torn down. The second is that address spaces in Coyotos are first class, where they are not in conventional systems.

Not sure what you mean by "processes are resource containers" or "resources are owned" (by a process). A file descriptor is an index into its file descriptor table, which points to an (open) file table entry, which points to an inode and things are garbage collected if their refcounts drop to zero when a process dies. One can think of a file descriptor as sort of a capability.

In UNIX/Windows, a Process contains threads and pages that make up an address space.  The Process "owns" these things, in the sense that when the process goes away, these other things also cease to exist.

More like a process owns only *reference* to these things. Given only one reference they naturally have to be GCed once a process disappears!

In Coyotos, a Process has a reference to an object that serves as its address space.  Several Processes can share an address space, and you can change the address space that a Process operates in.

[As a thought experiment, if Unix was to be made more "granular"]

One can imagine associating a "well-known file descriptor" with a process address space. With a few more enhancements one can implement execve(2) as well as possibly fork(2) in user-space by a "process keeper" process. And may be we can get rid of ptrace(2) for debuggers. And process-ids are then merely indices in a proc-fd table in the process keeper. Separating address spaces from processes would not be all that hard, and in fact would be needed if one were to allow process migrations. Envisioning such a evolution is why I don't think of a process owning threads, address space, page table, fd table etc. Also, in my mental model, devices are resources as well (and stick around independent of processes). Similarly a CPU resource is only "owned" only while a process thread is actually running. [Of course, actually "evolving" a unix OS in this direction is very unlikely...]

Cheers,

Bakul

[William ML Leslie]

On Mon, 15 Dec 2025 at 10:12, 'Bakul Shah' via cap-talk <cap-...@googlegroups.com> wrote:

[Oops, forgot to hit the send button...]

Thanks, William & Jonathan, for clarifying.

On Dec 11, 2025, at 8:25 PM, William ML Leslie <william.l...@gmail.com> wrote:

On Fri, 12 Dec 2025 at 13:59, 'Bakul Shah' via cap-talk <cap-...@googlegroups.com> wrote:

On Dec 11, 2025, at 6:40 PM, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

When explaining to people who are coming from UNIX or Windows processes, this can lead to trouble. There seem to be two points of confusion. The first is that UNIX/Windows processes are resource containers. Many of those resources are "owned", in the sense that if the process is torn down then those resources are torn down. The second is that address spaces in Coyotos are first class, where they are not in conventional systems.

Not sure what you mean by "processes are resource containers" or "resources are owned" (by a process). A file descriptor is an index into its file descriptor table, which points to an (open) file table entry, which points to an inode and things are garbage collected if their refcounts drop to zero when a process dies. One can think of a file descriptor as sort of a capability.

In UNIX/Windows, a Process contains threads and pages that make up an address space.  The Process "owns" these things, in the sense that when the process goes away, these other things also cease to exist.

More like a process owns only *reference* to these things. Given only one reference they naturally have to be GCed once a process disappears!

Usually there's a spacebank associated with the running process, and the bank is rigged to reclaim them when the process goes away.  But yes, in the general case, they are GC'd.

 

In Coyotos, a Process has a reference to an object that serves as its address space.  Several Processes can share an address space, and you can change the address space that a Process operates in.

[As a thought experiment, if Unix was to be made more "granular"]

One can imagine associating a "well-known file descriptor" with a process address space.

If you're running a unix domain program, you'll run it with some pid space.  You can have more than one pid table on the system.  I don't know to what extent KeyNIX supported that, but I'd assumed that was how it worked.  It's a regular capability though, no need to emulate through a file descriptor.  The differences between the native capability type and file descriptors are subtle but sometimes important, e.g. you probably reference count open files, wheras the native capability type does not leak that sort of information about its holders.

With a few more enhancements one can implement execve(2) as well as possibly fork(2) in user-space by a "process keeper" process.

Yes.  See VirtualCopySpace in the Coyotos source for an unfinished but efficient example of how userspace fork() could be implemented.  It mirrors how ElfSpace progressively copies static data from a backing image into owned, writable memory when the memory write faults.

And may be we can get rid of ptrace(2) for debuggers.

Shap has a plan for debug; I haven't extracted it from him yet.

 

Similarly a CPU resource is only "owned" only while a process thread is actually running.

What you do own is space to save your process state, notably the contents of your registers.  You also own a schedule, which is the ability to claim back the CPU at some future time.

 

[Of course, actually "evolving" a unix OS in this direction is very unlikely...]

¯\_(ツ)_/¯

I wonder if it would be easier to first do a WASM runtime and then use WANIX: https://github.com/tractordev/wanix/tree/v0.3-preview

I was knee deep in implementing a posix layer on top of Coyotos when I decided that async had to come first; I still don't think the design problems are that hairy.  And of course, it has been done before.  Norm said that it took an intern 6 months to add userspace support for System 5 binaries to KeyKOS (and that it was fast).  So, depending on your end goal, there are lots of options that might be worth exploring.

--

William ML Leslie

[Jonathan S. Shapiro]

On Sun, Dec 14, 2025 at 4:12 PM 'Bakul Shah' via cap-talk <cap-...@googlegroups.com> wrote:

On Dec 11, 2025, at 8:25 PM, William ML Leslie <william.l...@gmail.com> wrote:

In UNIX/Windows, a Process contains threads and pages that make up an address space.  The Process "owns" these things, in the sense that when the process goes away, these other things also cease to exist.

More like a process owns only *reference* to these things. Given only one reference they naturally have to be GCed once a process disappears!

Yes, technically, within the UNIX kernel there is a typically reference to the process's address space region list. There are two distinctions I was trying to draw:

1. That reference is an artifact of implementation; the "slot" that holds it cannot be assigned to point to a different region list. The process structure and its address space structures are 1:1, and are created and torn down in the same operation.
2. The address space has no identity or lifespan independent of its process. It is not first class. Though that's probably just a different way of articulating what I said in [1].
3. The same is true of the threads that make up the process. They are "owned" by their containing process.

In Coyotos, an address space is first class, and the lifespan of a process (a domain) has no intrinsic kernel-imposed relationship to the lifespan of a process that uses it. Multiple domains can reference the same address space. Not only can a domain's address space capability slot be updated to point to a different address space, but we actually use that feature to good purpose during the low-level bootstrap logic of the constructor.

Finally, there is no GC in Coyotos. If you want something torn down you have to do it by hand or destroy the space bank from which it was allocated.

In Coyotos, a Process has a reference to an object that serves as its address space.  Several Processes can share an address space, and you can change the address space that a Process operates in.

[As a thought experiment, if Unix was to be made more "granular"]

One can imagine associating a "well-known file descriptor" with a process address space. With a few more enhancements one can implement execve(2) as well as possibly fork(2) in user-space by a "process keeper" process. And may be we can get rid of ptrace(2) for debuggers. And process-ids are then merely indices in a proc-fd table in the process keeper. Separating address spaces from processes would not be all that hard, and in fact would be needed if one were to allow process migrations. Envisioning such a evolution is why I don't think of a process owning threads, address space, page table, fd table etc. Also, in my mental model, devices are resources as well (and stick around independent of processes). Similarly a CPU resource is only "owned" only while a process thread is actually running. [Of course, actually "evolving" a unix OS in this direction is very unlikely...]

There have been various operating system kernels that have explored more granular arrangements for process-related abstractions. If you approach this architecturally as a de novo design exercise, it's not that hard to imagine what it would look like. If you approach it starting from UNIX and asking "how would I rearrange this to look more granular", it seems much more complicated than it really is. The reason, I think, is that UNIX is already deeply committed to a set of OS-level abstractions that would need to be rearranged or completely re-thought in order for this to work.

One of the things I've been writing through recently is the difference between traditional "high level" OS abstractions and the abstractions in Coyotos that are much closer to the hardware machine. The Coyotos kernel doesn't really define a process model, for example. It defines an encapsulation of hardware execution and fault behavior that wraps exceptions and faults into messages and delivers them to applications to deal with. Those applications can set whatever policies and behaviors they wish, and it is those policies and behaviors that constitute a process model.

If you want to set up a UNIX-flavored cocoon that makes it look as if a process is running on a UNIX kernel, that's possible. I haven't explored it in depth, but I suspect you could do the same for many other operating systems. Each of these has its own process model, and it is possible to emulate that model by building appropriate fault handlers.

Jonathan

[Daira-Emma Hopwood]

On Mon, 15 Dec 2025, 00:06 Alan Karp, <alan...@gmail.com> wrote:

No more physical meetings since the pandemic.  Only Zoom.

Oh, that's a shame. I miss the social interaction from the few times I was able to physically attend Friam. Also: FFP3/N99 masks work, especially when everyone in a group is wearing them. I'm clinically vulnerable but I wouldn't have any issue with attending a physical meeting where everyone used FFP3/N99 masks. Is there any interest in that, perhaps as a hybrid meeting?

-- 

Daira-Emma Hopwood