Re: userapi: signals

[Peter da Silva <peter-dragonfly@xxxxxxxxxxx>]

Matthew Dillon wrote:
>     Correct.  So the same abstractions we use in the kernel could be used
>     in userland.  i.e. messaging between (rforked) processes, use of a
>     'critical section' to protect per-(rfork)-cpu data, localized scheduling,
>     and so forth.

Which is where I got down to the idea that it's going to make sense to 
treat all userland processes as threaded, the "non-threaded" case is 
just a degenerate case where there aren't any non-main threads. So you 
don't need threaded and non-threaded versions of the system calls. That 
also simplifies some of the potential issues I see with signal handling.

>     There are lots of ways to do this.  Perhaps the use of a pipe just for
>     notification (e.g. just write one byte and read-drain), or a SysV
>     semaphore, and transfer the messages directly via shared memory.

Aren't the first two going to be implemented using Dragonfly messages?

> :Do this right, and the UNIX system call emulator itself could run in the
> :kernel. Which opens up all kinds of interesting possibilities. It would
> :probably become possible to port dragonfly to hardware that doesn't
> :even have an MMU, like an Amiga 1000 or Palm III.

>     I really want the syscall emulator to run in usermode

Oh, hold on, I don't mean "move the emulator for a usermode process to 
the kernel", that would be silly for all the reasons you list and more.

I mean "there's hardly any distinction between a thread in kernel mode 
and a thread in user mode, except the way it sends messages to the 
kernel", which would mean the userapi could run almost unmodified in the 
kernel, which would mean you could do away with "user mode" altogether 
for an embedded system, while still being able to make all the same 
section-2 and section-3 calls through the userapi... so it could be 
developed as a bunch of processes before burning it to a ROM image.