1. 28 Nov, 2018 1 commit
  2. 03 Jul, 2018 1 commit
  3. 06 Jul, 2015 1 commit
  4. 29 Oct, 2014 1 commit
  5. 08 Jul, 2014 1 commit
  6. 14 Jun, 2014 1 commit
  7. 06 Jun, 2014 1 commit
  8. 17 Apr, 2014 1 commit
  9. 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
      policy.
      c17fca75
  10. 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
      instance.
      
      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.
      cee27b29
  11. 09 Sep, 2013 2 commits
  12. 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
      "personalities".
      
      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,
      i.e.:
      
      * 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).
      b569cd72
  13. 21 Jun, 2013 2 commits
  14. 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>/.
      629fa126
  15. 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.
      3667859d
  16. 11 Feb, 2013 1 commit
    • Philippe Gerum's avatar
      cobalt: move kernel-based Xenomai threads over native linux kthreads · c0e2b14d
      Philippe Gerum authored
      This is a long due change aimed at stopping the absolute non-sense of
      creating and managing non-linux threads in a linux kernel.
      
      Aside of a massive simplification of the low-level code, using native
      linux kthreads to support kernel-based Xenomai threads also gets rid
      of the braindamage non-linux stack contexts, which is quite of a
      relief.
      
      In addition, this introduces the secondary runtime mode for Xenomai
      kthreads, despite we don't expose it though any official interface for
      sanity reasons (i.e. we have no syscall interface to do the required
      fixups in case of mode mixing, so we don't want to open this feature
      broadly).
      c0e2b14d
  17. 07 Jul, 2012 1 commit
    • Philippe Gerum's avatar
      nucleus/sched: update scheduling class weights · da27f6e1
      Philippe Gerum authored
      This patch changes the respective weights of scheduling classes, in
      order to give higher priority to classes whose threads are not
      throttled by any sort of mechanism, over classes limiting the
      execution time of their threads.
      
      This gives us (in ascending priority order):
      
      IDLE
         => TP
             => PSS
                  => RT
      
      The net effect is that runnable RT threads will always be picked by
      the scheduler core before threads from other classes, which may be
      throttled by some class-specific mechanism.
      da27f6e1
  18. 28 Jan, 2012 7 commits
    • Philippe Gerum's avatar
      cobalt/nucleus: remove norm/denorm thread priorities · d7a30867
      Philippe Gerum authored
      We don't need to support normalized/denormalized priorities for
      threads, since both Cobalt and RTDM interfaces use the same priority
      scale.
      
      All APIs with non-POSIX scales now run in userland, handling
      conversions between Cobalt and their own priority scale locally from
      the Copperplate interface.
      d7a30867
    • Philippe Gerum's avatar
      cobalt/nucleus: sanitize RRB implementation · e9ce10b4
      Philippe Gerum authored
      Ticking at each individual base period while we undergo round-robin
      scheduling for a thread does not make any sense; all intermediate
      ticks are just 100% worthless overhead.
      
      We fix this by assigning an internal timer to each thread dedicated to
      round-robin scheduling. The thread's scheduling class still decides
      what to do upon expiration of the round-robin quantum, most likely
      requeue the target thread at the end of its priority group -- but
      something else/additional could be done if need be.
      
      The global time slicing timer disappears, along with the virtual tick
      configuration knob. A new XENO_OPT_RR_QUANTUM configuration symbol now
      defines the duration of the default time quantum for RRB scheduling.
      e9ce10b4
    • Philippe Gerum's avatar
      cobalt: remove kernel support for periodic time bases · 070298ca
      Philippe Gerum authored
      Using the POSIX/Cobalt and RTDM interfaces in coarse grain, tick-based
      mode does not make any sense, and periodic timing is now achieved for
      all other interfaces via Copperplate's clock services from userland,
      which induces significantly less overhead.
      
      Therefore, periodic time bases within the nucleus have no more users,
      and we get rid of the related code. The former "master timebase" is
      turned into the Xenomai system clock object (the former nkclock object
      was renamed nktimer, fixing a misnomer in the same move).
      
      As a result of this, another major simplification happens: there is
      one, and only one time unit which is now relevant for the entire
      Cobalt system: nanoseconds.
      070298ca
    • Philippe Gerum's avatar
      cobalt/nucleus: remove support for priority coupling (aka RPI) · 0879cc4a
      Philippe Gerum authored
      The former Xenomai architecture provided for priority coupling, a
      mechanism which makes the Linux kernel - as a whole - inherit the
      Xenomai-defined priority for a real-time thread running in user-space,
      when it enters the secondary execution mode, e.g. to perform regular
      Linux system calls.
      
      The purpose, pros and cons of such feature has been discussed in
      length over the years on the Xenomai mailing lists. A general
      consensus among contributors emerged about the limitations of such
      mechanism for properly tracking and propagating priority changes,
      which cannot be lifted due to dual kernel design issues.
      
      As a matter of fact, these limitations can be confusing to the end
      user, and may have caused wrong application designs in some
      occasions. Therefore we remove this support completely, moving back to
      the principle of least suprise in dual kernel environments,
      i.e. calling services of the non real-time kernel ALWAYS demotes a
      real-time caller to the lowest, non real-time priority level.
      0879cc4a
    • 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).
      d849c14e
    • 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.
      ddf911b2
    • Philippe Gerum's avatar
      ksrc: rename as kernel · 09f8992a
      Philippe Gerum authored
      09f8992a
  19. 03 Jul, 2010 2 commits
  20. 20 Sep, 2009 1 commit
  21. 03 Jun, 2009 1 commit
    • Philippe Gerum's avatar
      Introduce /proc/xenomai/schedclasses · 5a8336d7
      Philippe Gerum authored
      This PROC_FS hierarchy provides runtime information which relate to
      the scheduling classes built into the system. Each scheduler may
      export class-specific data there.
      5a8336d7
  22. 14 Feb, 2009 1 commit
  23. 27 Jan, 2009 1 commit
  24. 12 Dec, 2008 2 commits
  25. 11 Dec, 2008 2 commits
  26. 07 Dec, 2008 1 commit
  27. 25 Nov, 2008 1 commit