1. 28 Nov, 2018 1 commit
  2. 03 Jul, 2018 1 commit
  3. 29 Oct, 2014 1 commit
  4. 14 Jun, 2014 1 commit
  5. 21 May, 2014 1 commit
    • Philippe Gerum's avatar
      cobalt/sched: increase the visible priority range of real-time classes · 3824f705
      Philippe Gerum authored
      There is no point in limiting the available priority range to 99 for
      all classes but SCHED_COBALT, although we support up to 258 distinct
      levels internally.
      POSIX explicitly states that such limit is implementation-dependent,
      and provides for sched_get_priority_max() for retrieving it
      dynamically. Applications wary of portability between the Cobalt and
      Mercury cores should probe for such limit.
      All real-time classes exposed to userland now support up to 256 levels
      [0..255], except SCHED_COBALT which gives access to the widest range
      [0..257] available internally.
  6. 17 Apr, 2014 1 commit
  7. 14 Apr, 2014 1 commit
    • Philippe Gerum's avatar
      cobalt/sched: use fixed level range for O(1) scheduler · c17fca75
      Philippe Gerum authored
      Fix the valid range of runlevels in the O(1) scheduler queue to
      [XNSCHED_RT_MIN_PRIO..XNSCHED_RT_MAX_PRIO], as threads may cross
      policies freely during PIP boosts, therefore all possible priority
      level must be valid for all scheduler queues, regardless of the
  8. 20 Dec, 2013 1 commit
    • Philippe Gerum's avatar
      cobalt/sched: introduce sched_kick() handler for policy modules · cee27b29
      Philippe Gerum authored
      Scheduling policies may prevent threads from running based on some
      extra state, by not returning them from the sched_pick() handler,
      without reflecting such state with any block bit. Those threads remain
      in the ready state from the scheduler core point of view, although
      they won't be elected for running.
      This behavior is typical of policies enforcing a runtime budget for
      However, we also have to honor the request to move a thread out of
      primary mode (i.e. shadow kicking). Therefore we need a way to tell
      the policy module to release such thread temporarily, until it
      eventually relaxes (e.g. sigwake -> kick -> relax).
      To this end, the sched_kick() handler can be defined by policy modules
      for dealing with this specific case. It is called for kicked threads
      bearing the XNREADY bit, once all block bits have been lifted.
  9. 09 Sep, 2013 1 commit
  10. 10 Aug, 2013 1 commit
    • Philippe Gerum's avatar
      cobalt/kernel: remove pod abstraction entirely · b569cd72
      Philippe Gerum authored
      We don't have full-fledged in-kernel APIs going in and out selectively
      anymore, we now have a stable set of API services (i.e. core, POSIX
      and RTDM), with optional limited extensions through Xenomai
      For this reason, the former "pod" abstraction, as a mean to group
      multiple API siblings in a common generic container is not much
      relevant anymore.
      The ongoing design simplification now allows to drop the pod-related
      services, dispatching them to the other existing abstractions.
      The renaming involved are fairly straightforward for the most part,
      * Former thread-directed ops:
        xnpod_<action>_thread() => xnthread_<action>()
      * Former scheduler-related ops:
        xnpod_<action>() => xnsched_<action>()
      Hint: xnpod_schedule() became xnsched_run() (although xnsched_ule()
      would have been delighting).
  11. 21 Jun, 2013 2 commits
  12. 18 Jun, 2013 1 commit
    • Philippe Gerum's avatar
      kernel/cobalt: reorganize file hierachy · 629fa126
      Philippe Gerum authored
      The main changes introduced are as follows:
      - Xenomai/cobalt core (nucleus) moved at top level, with the arch-dep
      bits, POSIX and RTDM personalities in sub-directories.
      - Renamed include/cobalt/nucleus to include/cobalt/kernel.
      - include/asm-* directories moved to include/cobalt/.
      - Removal of asm-<arch>/bits, with most code reintroduced as regular
        implementation files into lib/cobalt/sysdeps/<arch>/.
  13. 12 Jun, 2013 1 commit
    • Philippe Gerum's avatar
      cobalt/nucleus: introduce SCHED_WEAK scheduling class · 3667859d
      Philippe Gerum authored
      This code enables support for binding threads from the Linux
      SCHED_FIFO/RR scheduling classes to the Xenomai domain as members of
      the SCHED_WEAK class, with up to 100 priority levels from [0..99]
      included.  When enabled, SCHED_WEAK is the low priority class of the
      Xenomai system, providing no real-time guarantee.
      Members from the SCHED_WEAK class are weakly scheduled by Xenomai,
      only for the purpose of synchronizing with real-time threads from
      other scheduling classes.  However, they cannot compete for CPU
      resources with real-time threads, and leave the primary domain upon
      return from Xenomai syscalls automatically (*).
      This feature is an extension of Xenomai's special handling of
      SCHED_OTHER threads, to the SCHED_FIFO/RR POSIX classes from a regular
      Linux kernel. If disabled, SCHED_WEAK is interpreted as an alias to
      SCHED_OTHER by the Xenomai scheduler, restricted to priority
      0. Conversely, SCHED_OTHER threads are eventually members of Xenomai's
      SCHED_WEAK class at priority 0, when this feature is enabled.
      In the wake of the SCHED_WEAK introduction, automatic propagation of
      updates to the Xenomai scheduling parameters to linux/libc via the
      SIGSHADOW_RENICE signal has been removed.
      (*) Like with SCHED_OTHER, Xenomai assumes no real-time requirement
      for SCHED_WEAK threads. Therefore, they are automatically moved back
      to secondary mode upon return from a Xenomai syscall, unless they hold
      a mutex, which would defer the transition until the mutex is released.