DragonFly kernel List (threaded) for 2003-07
Re: userapi: signals
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.