DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: userapi: signals

From: Peter da Silva <peter-dragonfly@xxxxxxxxxxx>
Date: Tue, 22 Jul 2003 12:45:59 -0500

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.

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]