This patch adds functionality to request an asynchronous notification
if some other process has send a message to it. We currently send a
SIGALRM to avoid any changes to core infrastructure of signal handling.
Ideally we should implement a separate signal for this. Currently there
is an obvious disadvantage of not being able to use SIGALRM with alarm,
if we are using this functionality.
Currently we only allow users to get and set number of queues. The
operation is always non blocking. There is no provision for non
blocking operation at the moment.
The queue sizes are set to MAX 256 by default. If a user changes the
attributes and sets the queue size or number of messages in a queue
to less than 256, it is the responsibility of the user to close any
queues which were opened with a descriptor greater than the value
currently set.
For example, by default queue sizes are 256. If 150 queues are opened
and then the user sets the number of queues to 32, all open descriptors
and queues from 32 to 150 must be closed. Note that descriptor number
allocation starts with zero and not one.
Implement message queues support for Minix.
Pending tasks:
Blocking or non blocking for send receive?
Sort by priority and time?
Test codes?
Bug fixes?
- the userland call is now made to PM only, and PM relays the call to
other servers as appropriate; this is an ABI change that will
ultimately allow us to add proper support for wait3() and the like;
for the moment there is backward compatibility;
- the getrusage-specific kernel subcall has been removed, as it
provided only redundant functionality, and did not provide the means
to be extended correctly in the future - namely, allowing the kernel
to return different values depending on whether resource usage of
the caller (self) or its children was requested;
- VM is now told whether resource usage of the caller (self) or its
children is requested, and it refrains from filling in wrong values
for information it does not have;
- VM now uses the correct unit for the ru_maxrss values;
- VFS is cut out of the loop entirely, since it does not provide any
values at the moment; a comment explains how it should be readded.
Change-Id: I27b0f488437dec3d8e784721c67b03f2f853120f
Previously, there was a tiny chance that tickdelay(3) would return
early or that it would fail to reinstate a previous alarm.
- sys_setalarm(2) now returns TMR_NEVER instead of 0 for the time
left if no previous alarm was set;
- sys_setalarm(2) now also returns the current time, to allow the
caller to determine whether it got an alarm notification for the
alarm it set or for a previous alarm that has just gone off;
- tickdelay(3) now makes use of these facilities.
Change-Id: Id4f8fe19a61ca8574f43131964e6f0317f613f49
The entire infrastructure relied on an ACK feature, and as such, it
has been broken for years now, with no easy way to repair it.
Change-Id: I783c2a21276967af115a642199f31fef0f14a572