RE: [MiNT] kernel 1.15.10b fragmentation

["Sven Karlsson" <svenka@it.kth.se>]

Hi all,

> Do you have ideas for fast and flexible enough IPC mechanism that match
> your requirements?

I think the messaging primitives from the Fenix kernel would fit like a
glove. They enable processes (or threads as it is in Fenix) to communicate
using small fixed size messages. These small messages are put in a
preallocated buffer called port (each process can extend the buffers of the
ports they own.). Any thread that has the identity of a port can send
messages to it. Fenix has both blocking and unblocking messages and I
suggest both should be implemented into the kernel if this proposal gets
into MiNT. Each process can have an arbitrary number of ports.

Fenix synchronize threads using "thread signals" that are similar to UNIX
signals but each thread has it's own signal set. These are used to be able
to read messages from multiple message ports.

The Fenix kernel use a private trap vector for its primitives and send
parameters in registers. I suggest this convention is kept to keep
compatibility with Fenix.

I propose that these primitives are inherited from Fenix:

*messages and message ports
 *receive message
 *send message
 *poll message
 *create message port
 *destroy message port
*thread signals
 *send signal(s)
 *wait on signalmask
 *poll signals
 *allocate and free signals
*the fenix calling convention

The only things AFAICS these primitives need are access to kernel memory,
the process structure and a mean to put the current process to sleep and
wake another up. All these are available IIRC (it has been a while since I
worked on the kernel). Since there is only one thread per process in MiNT
(or has that changed recently?) each process would behave as an thread under
Fenix.

The Fenix kernel very small and I would think you could implement the
primitives above in less than 1 k of object code.

I'm pretty tired ATM but I hope this is in at least to a certain degree
understandable. Johan can give comments as he has seen the kernel and can
hopefully see what I am talking about. I'll get back with more detailed
information.

Comments?

Regards
 Sven

ps. The messages are of course used to convey information that needs to be
sent between the kernel and user part of the AES. This scheme is easily
extended to a distributed system if one would like that. ds.

ps. The thread signals are very powerful. They are the best thing in AmigaOS
and I samelessly stole the idea from there. The current scheme is quite
different from AmigaOS though. Thread signals could be used to implement a
select() capable of selecting from an arbitrary number of files and sockets.
ds.