1. 19 Mar, 2019 1 commit
  2. 24 Sep, 2018 1 commit
  3. 22 May, 2015 1 commit
  4. 17 Feb, 2015 1 commit
  5. 01 Jan, 2015 1 commit
    • Jan Kiszka's avatar
      cobalt/pipe: Avoid running init_waitqueue_head under xnlock · ed6465cc
      Jan Kiszka authored
      This operation can be more complex than simple structure initialization,
      namely if lockdep is enabled.
      
      The approach take here is to break up user connection into two stages.
      The first one is "lingering connection", which simply reserves the pipe
      for the caller of xnpipe_open. After that we release xnlock, perform the
      Linux part of the initialization and then finish the second stage under
      xnlock again to reach USER_CONN just as before.
      
      This issue can be triggered by running smokey test #10 (xddp).
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      ed6465cc
  6. 21 Sep, 2014 1 commit
  7. 08 Sep, 2014 1 commit
    • Philippe Gerum's avatar
      cobalt/heap: drop support for heap extension · 641dd175
      Philippe Gerum authored
      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.
      641dd175
  8. 12 Aug, 2014 1 commit
  9. 14 Jun, 2014 1 commit
  10. 10 Aug, 2013 2 commits
    • 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
    • Philippe Gerum's avatar
      cobalt/kernel: introduce external clock support · 28eb37c8
      Philippe Gerum authored
      This patch introduces a mechanism for registering external clocks
      dynamically, in addition to Xenomai's built-in core clock
      (nkclock). Each external clock may drive Xenomai timers (struct
      xntimer) using the common timer infrastructure.
      
      Xenomai's core clock has nanosecond resolution; it is paced by the
      platform timer (which is driven by the interrupt pipeline).
      
      External clocks are driven by arbitrary timer sources, directly
      managed by the client code.
      
      Each clock provides an internal interface with the timer support code,
      through a set of common operations (e.g. reading time, converting time
      values, programming the next shot if applicable).
      
      The external interface is pretty simple:
      
      - xnclock_register() for instantiating a new clock
      - xnclock_deregister() for dropping an existing clock
      - xnclock_tick() for signaling an incoming tick, so that
        timers driven by the clock are elapsed appropriately.
      
      Since we may now have multiple clocks, each driving their own set of
      timers, the /proc/xenomai/clock/ v-file tree has been introduced for
      exporting the per-clock timer statistics. The former
      /proc/xenomai/timerstat exposing the core clock stats becomes
      /proc/xenomai/clock/coreclk.
      
      External clock support is enabled by turning on the internal
      CONFIG_XENO_OPT_EXTCLOCK switch. This toggle is NOT accessible by the
      user, it is reserved to other kernel components interfaced with the
      Xenomai core.  When disabled, all clock-related operations are
      hard-wired to Xenomai's core clock (nkclock).
      28eb37c8
  11. 29 Jun, 2013 5 commits
    • Philippe Gerum's avatar
    • Philippe Gerum's avatar
      cobalt/kernel: drop __clrbits() · 3bfbdff8
      Philippe Gerum authored
      Same as __setbits, this macro does not bring anything useful compared
      to an explict bitwise operation.
      3bfbdff8
    • Philippe Gerum's avatar
      cobalt/kernel: drop __setbits() · 0dc7e030
      Philippe Gerum authored
      This non-atomic form cannot operate on any arbitray bit number like
      __set_bit() but rather works with a plain bitmask. There is no point
      in obfuscating the code via this indirection. Drop it.
      0dc7e030
    • Philippe Gerum's avatar
      cobalt/kernel: drop [__]testbits · 2f6ba504
      Philippe Gerum authored
      This macros bring no value. Prefer explicit, open coded bitwise tests.
      2f6ba504
    • Philippe Gerum's avatar
      cobalt: introduce uapi headers · d928926f
      Philippe Gerum authored
      Following the uapi introduction in recent kernels, this jumbo patch
      splits the former Xenomai POSIX headers into kernel and userland
      counterparts, privatizing the former into the kernel section when
      applicable.
      
      This change is aimed at centralizing the shared API types and
      definitions used in system calls, making it easier to track changes to
      the APIs that the kernel presents to user space, and solving inclusion
      dependency issues the right way.
      
      Headers defining the API bits shared between the Cobalt kernel and the
      support libraries in userland are available from include/cobalt/uapi,
      organized as follows:
      
      - uapi/*.h => Cobalt/POSIX interface bits
      - uapi/rtdm => RTDM bits
      - uapi/sys/*.h => Low-level Cobalt kernel bits
      
      As a consequence of this split, files below include/cobalt/kernel
      become kernel-only headers, and POSIX headers in include/cobalt are
      exclusively reserved for inclusion in user-space builds.
      
      As an added benefit, this change significantly reduces the number of
      headers to be installed for building Xenomai applications.
      d928926f
  12. 25 Jun, 2013 1 commit
    • Philippe Gerum's avatar
      cobalt/kernel: drop xnflags_t · 575c762a
      Philippe Gerum authored
      This abstraction is overkill and logically wrong. What we want is two
      mutually convertible types:
      
      - a portable base type which is wide enough for representing a set of
        bitwise conditions/statuses. Therefore, this type still has to be
        32bit wide at most nowadays.
      
      - another type which can be used with atomic operations on any
        platform, typically a long integer type.
      
      We drop xnflags_t, replacing it with a basic int type in function
      prototypes, or long integer type when atomic operations are involved
      internally. At any rate, atomic operations will produce significant
      results for us only for the first 32 LSBs of such word.
      575c762a
  13. 21 Jun, 2013 2 commits
    • Philippe Gerum's avatar
    • Philippe Gerum's avatar
      cobalt/kernel/synch: turn pendq into regular kernel list · 91a51f0f
      Philippe Gerum authored
      This is the first patch of a (long) series aimed at gradually
      replacing xnqueue data structures with regular list_head
      objects.
      
      Legacy Xenomai queues and kernel lists will live in parallel, until
      the rebase is complete, at which point include/cobalt/kernel/queue.h
      will be dropped from the tree.
      
      The motivation is to better comply with kernel standards and remove
      all useless overhead and specifics about Xenomai queues/lists.
      
      For instance, the element count maintained by the xnqueue object is
      most often used only for testing for emptiness, which makes it
      overkill. The few users of the actual item count should rather do
      their own accounting instead.
      91a51f0f
  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. 20 Dec, 2012 1 commit
  16. 14 Dec, 2012 1 commit
    • Philippe Gerum's avatar
      cobalt: remove HAL interface · bb4f2d90
      Philippe Gerum authored
      Originally, the HAL interface was aimed at abstracting the real-time
      enabler on top of which the nucleus sits, when running over the linux
      kernel. Along the years, we only used the Adeos pipeline for this
      purpose, and 3.x is writing this dependency in stone for the Cobalt
      core.
      
      Therefore the HAL layer becomes pointless, and removing it simplifies
      a great deal of low level Xenomai code, making architecture ports even
      simpler.
      
      In the same move, we dismiss support for legacy pipelines. A pipeline
      from the recent "core" series, exposing API revision #2 or better is
      required to build and run Xenomai 3.x.
      
      NOTE: nios2 and sh4 are not ready for prime time, since we don't have
      a core pipeline implementation for them yet. We leave them in tree
      though, waiting for catch-up.
      bb4f2d90
  17. 20 Aug, 2012 1 commit
  18. 07 Jul, 2012 1 commit
  19. 28 Jan, 2012 5 commits
    • Philippe Gerum's avatar
      hal, nucleus, rtdm, drivers, scripts: rebase over the IPIPE_CORE API internally · 1aa7f792
      Philippe Gerum authored
      We will soon be switching all I-pipe implementations to the latest
      "pipeline core" API specification.
      
      This patch makes all Cobalt internals use the new pipeline core API,
      providing an emulation of it over the legacy I-pipe interface, until
      all architectures have caught up with the new specification.
      1aa7f792
    • 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
    • Philippe Gerum's avatar
      ksrc, scripts: remove pre-2.6.30 kernel support · 3cb7d6f7
      Philippe Gerum authored
      One of the promises of the 3.x architecture is to get rid of the
      ancient kernel legacy, which is 1) a pain to maintain via hairy
      wrappers, 2) a restriction on using recent kernel features to improve
      the Xenomai core.
      
      This patch cuts off pre-2.6.30 support for now, but it is very likely
      that we will move this barrier up, depending on what non-major CPU
      arch ports can be based on in a reasonable future (typically nios).
      3cb7d6f7
  20. 06 Sep, 2011 1 commit
  21. 19 Jun, 2011 1 commit
    • Philippe Gerum's avatar
      nucleus: fix ioctl() prototypes for pre-2.6.11 · 35849a78
      Philippe Gerum authored
      The file inode argument disappeared from the unlocked ioctl()
      signature which we have been using since 2.6.11, compared to the old
      (locked) form used in older kernels.
      
      Pick the appropriate signature for Xenomai ioctl() handlers
      conditionally, depending on whether the locked or unlocked form is
      being used under the hood.
      35849a78
  22. 09 Oct, 2010 1 commit
    • Philippe Gerum's avatar
      hal/generic, nucleus: remove PREEMPT_RT specifics · 09e79ca8
      Philippe Gerum authored
      This patch cleans up the outdated PREEMPT_RT experimentation code from
      the current dual kernel architecture. Combining dual kernel and native
      preemption technologies in a single kernel does not make much sense
      these days.
      09e79ca8
  23. 24 Sep, 2010 1 commit
  24. 31 Aug, 2010 1 commit
  25. 28 Aug, 2010 1 commit
  26. 03 Jul, 2010 1 commit
  27. 18 Mar, 2009 1 commit
  28. 24 Feb, 2009 1 commit
  29. 14 Feb, 2009 1 commit
  30. 28 Jan, 2009 1 commit