Re: syscall messaging interface API

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

Matthew Dillon wrote:
> 	* Queue and perform an upcall managed by a critical section (the
> 	  kernel would check to see if the user thread is in a critical
> 	  section and if so would just flag it.  The userland would later
> 	  detect that flag and flush the kernel's message queue).

This could technically be handled in userland, you know, but having
the upcall return "I'm in a critical section". Having the kernel
handle it would be more efficient if there are a lot of messages,
but it would require interacting with the kernel every time you
enter a critical section... wouldn't that be expensive?

> 	Ask the kernel to block until a message has been returned, or until
> 	a message is pending on the specified (userland) mesasge port, or
> 	both.

Would you want to block on a message, rather than on a port? Blocking
on a message would be a userapi function.

>     I believe that this gives us flexibility we need.  I have also come up
>     with a novel solution for signaling!  The userland would queue
>     'signal' messages to the kernel.  The kernel would then 'return' the
>     appropriate signal message when the signal occurs.  This gives userland
>     complete control (via the reply port) on how to deal with signals.

>     A similar form can be used for things like periodic timer requests...
>     they can stay 'live' in the kernel and simply be returned over and over
>     again to the userland.

Gee, that looks familiar.

>     I know this sounds somewhat complex but it provides us with the greatest
>     flexibility as well as an incremental development approach.

It doesn't sound complex at all, it's a pretty normal set of calls
for a realtime OS. Compare it to RSX: The upcalls are like ASTs,
waiting on a message port is like waiting on an event flag. Sending
a message is like a QIO.

You need a few more calls to complete the general design, to create
IPC ports, to publish them in an appropriate naming domain (UNIX
file system at least), and pass them over a port or a file descriptor
to another userland program... but these can wait until the basic
system is done. We just need to make sure there's no assumption in
the design that precludes them.

A couple of elaborations from RSX might come in handy: an equivalent
of WFLOR that would allow you to wait on multiple ports at once, for
example, and a way to signal an AST over a port.