1. 28 Nov, 2018 1 commit
  2. 03 Jul, 2018 1 commit
  3. 29 Oct, 2014 1 commit
  4. 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.
  5. 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).
  6. 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>/.
  7. 28 Jan, 2012 3 commits
    • Philippe Gerum's avatar
      posix: rename as the cobalt interface · d849c14e
      Philippe Gerum authored
      include/posix contents have moved to include/cobalt, lib/posix is
      renamed lib/cobalt and libpthread_rt becomes libcobalt. Conversely,
      the nucleus core becomes a building part of the cobalt interface.
      Rationale: the Cobalt-based POSIX interface becomes the core API over
      which all copperplate-based APIs are based. It is therefore defining
      for this real-time core, and as such should inherit its name.
      This also removes any occurrence of posix/, which makes the naming
      less ambiguous with respect to glibc's POSIX support we otherwise rely
      on fully when based over the Mercury core.
      This change conveys a strong hint about the fact that any additional
      skin we may want to introduce should be built over the copperplate
      interface in userland, and not directly implemented over the
      nucleus. This is a requirement for allowing its use over the Mercury
      core seamlessly. To this end, both the Cobalt/POSIX skin and the
      copperplate library can be extended internally to support the required
      features (e.g. additional scheduling policies).
    • Philippe Gerum's avatar
      kernel: move dual kernel support under cobalt/ root · ddf911b2
      Philippe Gerum authored
      The former nucleus directory becomes the root of all dual-kernel
      specific kernel code as "cobalt", which also contains the posix,
      native and rtdm sub-directories.
      Rationale: the base kernel code we should provide is now well-bounded,
      split as follows:
      - the dual kernel bits which include the nucleus and the few remaining
        core interfaces, we will use to iron a non-rt vanilla kernel for
        delivering real-time capabilities.
      - the native linux based code, basically the RTDM interface ported to
        the vanilla kernel.
      At this chance, we may group all dual kernel bits inside the same tree
      hierarchy since we now have a well-defined and bounded base kernel
      support which should not significantly grow over time (this reasoning
      obviously excludes RTDM-based drivers). As a matter of fact, only the
      existing core interfaces should live in kernel space, all others
      should live in userland over the copperplate library, so that we can
      use them over vanilla (rt or even non-rt) kernels as well.
      The same way, the RTDM implementation over vanilla kernel services
      should be rooted under a future "mercury" directory at some point.
    • Philippe Gerum's avatar
      ksrc: rename as kernel · 09f8992a
      Philippe Gerum authored
  8. 03 Jul, 2010 1 commit
  9. 20 Sep, 2009 1 commit
  10. 27 Jan, 2009 1 commit
  11. 09 Dec, 2008 1 commit
  12. 07 Dec, 2008 1 commit
  13. 25 Nov, 2008 1 commit
  14. 16 Sep, 2007 1 commit
  15. 19 Jun, 2007 1 commit
  16. 12 Jun, 2007 1 commit
  17. 04 Feb, 2006 1 commit
  18. 01 Nov, 2005 1 commit