Re: [ECOS] Variable size Message boxes

[Bart Veer <bartv at redhat dot com>]

>>>>> "Jifl" == Jonathan Larmour <jlarmour@redhat.com> writes:

    <snip>

    >> The former would require some form of dynamic memory
    >> allocation, i.e. if you post to a full message box then the
    >> kernel would need to extend the message box.

    Jifl> There's a simpler way to do it. Just make the kernel message
    Jifl> boxes take void *'s, and then it is up to the *application*
    Jifl> to malloc stuff, and then when it is received, free it. That
    Jifl> is the intended use of the kernel message boxes to make the
    Jifl> implementation simplest and fastest.

That is fine for the messages themselves, and cyg_mbox_put() etc.
already take void* arguments to support this. It is not always
sufficient. The presence of a message in a message box acts as an
event count as well as a data transfer, and typically you will
need to preserve the event count semantics. Manipulating messages
that have already been posted with malloc() and free() will not do
this. 

The current message box implementation requires an array to hold
messages that have been posted but not retrieved. It is that array
which would become variable-sized, i.e. which might need dynamic
memory allocation when posting. Less efficient, there are more things
that could go wrong, and not supported at this time.

Alternatively it would be possible to pass this array and its size as
arguments to the initialization routine. Then the post code would have
to check against a per-mbox maximum queue size rather than a constant
to determine whether or not the operation should block. You might even
want to add a control operation that lets you change the array at
run-time.

Or you can define a message box that works in terms of a linked list
and force application code to supply the requisite list nodes as part
of the message. Again there is no support for message boxes that work
along those lines.

Bart