GitLab

Although unusual, omitting open/socket/close handlers in drivers is
perfectly legitimate, and nothing justifies to keep them required.

A Cobalt/POSIX time value is a count of ticks with each tick
representing a nanosecond, so xnticks_t can and should be used. We
don't deal with hardware time stamp counters at this level, so there
is no ambiguity.

For consistency with timer_settime(), and also because the current
thread is assumed to receive the notifications if TFD_WAKEUP is set.

Pulling memory from the system heap for logging such debug data has
two adverse effects:

- it might gradually deplete the core heap due to a constantly
  misbehaving application,

- it may leave the user under the (wrong) impression that a memory
  leak is ongoing in the core heap, when a sane application is
  restarted multiple times, which invariably causes a few relax spots
  to be logged during the init phase.

We fix this by assigning a private memory pool for this debug
feature. Traces will simply stop being logged when the pool is full,
until /proc/xenomai/debug/relax is written to for flushing it.

Zero users, no purpose.

The allocator cannot handle more than 2Gb of storage area by design,
and the uapi/ bits already assume that sizes and offsets produced by
Cobalt heaps fit in a 32bit word, for 32/64 ABI neutrality.

Therefore we may turn all relevant long types to u32 in the
implementation, to clearly state the addressing limit of this
allocator.

Now that we have a single contiguous storage area with no embedded
meta-data attached to the base heap, we may retrieve the size and base
memory information directly from it.

Since we only don't have application-level code using our heap-based
allocator anymore, any invalid block pointer passed to xnheap_free()
would mean that some core code is definitely broken.

In response to such event, we now bluntly freak out and panic upon
detection of a bad pointer if CONFIG_XENO_OPT_DEBUG_COBALT is
enabled. Otherwise, xnheap_free() silently returns ignoring the
request.

As a consequence of this, xnheap_test_and_free() is dropped in the
same move, since a block pointer should always be valid at this
interface level, or the Cobalt kernel will pull the break if asked to.

In-kernel users only maintain fixed-size heaps, so there is no upside
in making the latter extendable, but only useless overhead. This patch
drops the support for the "extent" abstraction, assuming a single
contiguous storage area for any given heap.

In addition, the page map meta-data is moved away from the
user-defined storage area, so that the client code may actually
receive the full amount of memory it gave us originally (barring the
external fragmentation).

The page map is allocated internally instead via kmalloc(), which adds
the secondary_mode_only() requirement for both xnheap_init() and
xnheap_destroy(). All existing callers are fine with this already.

We don't need to support dynamically-defined page size anymore, as we
may claim that all client code can use the same value optimally. We
fix this value to the underlying VM page size.

This information does not bring any valuable information compared to a
commit #, with respect to which code release is actually built. In
addition, it also triggers a warning when -Wdate-time is enabled with
gcc >= 4.9.

We change the way application processes bind to the private and shared
memory heaps used in fastsync support. Aside of an obscure and
outdated implementation, using /dev/rtheap for this purpose led to a
couple of nasty issues:

- the requirement for abusing mmap()'s offset argument in the no-MMU
  case, so that different processes can map in distinct private heap
  areas.

- as a consequence of the previous point, the exposure of kernel
  addresses to userland (passed as differenciating "area" tags in the
  mapping offset) creates an issue with mixed 32/64bit ABI models.

To fix this, we introduce built-in, RTDM-based memory device drivers
in the Cobalt kernel (aka "UMM" for user-mapped memory), which expose
mmap() interfaces for binding to the proper private or shared
heap. The drivers are called by lib/cobalt when initializing a new
application process, to perform all the necessary mappings.

In addition, a third built-in driver honors (read-only) requests to
get status information about the system heap.

The legacy Cobalt tag sitting on the LSB part of the syscall code did
not cope well with the requirement for extending the numbering range,
for supporting the 32->64bit ABI models.

We fix this by reserving bit #28 as a marker for all Cobalt syscalls
(__COBALT_SYSCALL_BIT), which is still compatible with the I-pipe's
current syscall routing rules (i.e. call nr >= NR_syscalls being sent
unconditionally to the head domain).

For all archs, we now have:

nr = syscall_register & ~__COBALT_SYSCALL_BIT.

NOTE: when received, a Cobalt syscall has NOT been cleaned up from any
ABI mode tag bit which might belong to the host kernel,
e.g. __X32_SYSCALL_BIT may be present in syscall_register(orig_ax)
when received for handling an x32 call by a x86_64 host kernel.  Which
means that in the x32 case, we would have to filter out this extra bit
as well:

nr = syscall_register & ~(__X32_SYSCALL_BIT|__COBALT_SYSCALL_BIT).