Modify the status code returned by _CORE_message_queue_Submit() when it
detects a wait about to happen in an ISR (which would be deadly) to
return a status which translated to EAGAIN instead of ENOMEM.
This is only relevant for POSIX message queues, since Classic API message
queues cannot block on send.
The motivation is to match the "most related" errno value returned from
mq_send() and mq_timedsend() according to POSIX, via Open Group:
[EAGAIN]
The O_NONBLOCK flag is set in the message queue description
associated with mqdes, and the specified message queue is full.
or via the RTEMS POSIX users documentation
EAGAIN
The message queue is non-blocking, and there is no room on the queue
for another message as specified by the mq_maxmsg.
Neither of these matches the case ofi avoided ISR wait perfectly, but
they seem to be the closest equivalent, unless it is desirable to keep a
new non-standard error for this case. It is presumed that this is not
desirable.
The previously returned ENOMEM error value is not documented in either
the Open Group or the RTEMS POSIX uses documentation. A companion patch
corrects the documentation to include this error condition.
Based on the discussion in:
https://lists.rtems.org/pipermail/devel/2020-January/056891.htmlcloses#3857.
Message-Id: <CAF9ehCW5P12ZkZja4UPYTbdBFUyC1VKVL-tU7nyUtvK1Lz2Z3g@mail.gmail.com>
This adds support for the GICv3 interrupt controller along with the
redistributor to control SGIs and PPIs which wasn't present in GICv2
implementations. GICv3 implementations only optionally support
memory-mapped GICC interface interaction and require system register
access be implemented, so the GICC interface is accessed only
through system registers.
The FACE Technical Standard, Edition 3.0 and later require the definition
of the subcommand SOCKCLOSE in <devctl.h>.
Reference: https://www.opengroup.org/facecloses#3856.
The BSP tried to get the size of the SDRAM based on the revision code.
Unfortunately the code had some bugs so that the default size has been
used. Beneath that the MMU table hasn't been adapted.
This patch queries the SDRAM size via a special VC Mailbox call instead.
For the MMU adaption a simmilar method to the one in the imx BSP is
used.
The imx BSP contained a hack to change the workspace entry of the MMU
table. This makes the used define visible for other BSPs too so that the
same hack can be used for example in raspberry pi too.
Resource leak identified by Coverity (CID 1456675). The value
of instances is leaked in case some but not all irq servers are
created. It should be stored in bsp_interrupt_server_instances.
Use CONFIGURE_MAXIMUM_PROCESSORS to configure the EDF SMP scheduler
context. This avoids hard to debug configuration errors resulting in
memory corruptions.
Close#3815.
Obsolete undocumented configuration options CONFIGURE_MAXIMUM_FIFOS and
CONFIGURE_MAXIMUM_PIPES. Replace these options with the new
CONFIGURE_IMFS_ENABLE_MKFIFO configuration option.
Update #3840.
Two use cases were envisioned for this.
1) a BSP or application which desires to update a real-time clock
when the RTEMS TOD is set.
2) a paravirtualized BSP can use this to propagate setting the time
in an RTEMS application to the hosting environment. This enables
the entire set of applications in the virtualized environments
to have a single consistent TOD.
The MrsP semaphore implementation predates the addition of
self-contained synchronization objects. At this time, the potential
memory reduction was justified considering the more complex
configuration and additional use of the workspace. With the
availability of self-contained synchronization options, e.g. POSIX
mutexes, this is no longer justified. Memory constrained applications
should use the self-contained synchronization objects. Remove the
CONFIGURE_MAXIMUM_MRSP_SEMAPHORES configuration option. This has only an
impact on applications which use SMP and a large number of scheduler
instances.
Update #3833.
