1. 31 Jan, 2020 1 commit
    • Philippe Gerum's avatar
      cobalt/registry: fix export/unexport race on object deletion · 997b8e18
      Philippe Gerum authored
      Running xnregistry_enter() then xnregistry_remove() in quick
      succession for the same object might cause the latter to NULLify the
      objaddr field while proc_callback() is busy calling the vfile export
      handler for the object, which is going to use that same value,
      certainly leading to a crash.
      
      This bug is due to the asynchronous nature of the vfile
      export/unexport process which is deferred to a regular workqueue on
      the root stage when kicked from the head stage.
      
      Fix this by adding a third logic state describing an aborted vfile
      export procedure, due to handling an object removal request while the
      workqueue is concurrently running for the same object. In addition,
      since an exported object might be stale before it is considered for
      export, do not anticipate on the next object to process in
      proc_callback() as list_for_each_entry_safe() would do, but always
      pick the list head under lock.
      
      At this chance, clarify the naming of the magic vfile values
      enumerating those states (i.e. XNOBJECT_EXPORT_xxx).
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      997b8e18
  2. 05 May, 2017 1 commit
  3. 01 May, 2016 1 commit
  4. 12 Feb, 2016 1 commit
    • Philippe Gerum's avatar
      cobalt/registry: return -EAGAIN upon lack of registry slot · 364a91b4
      Philippe Gerum authored
      -ENOMEM is confusing in this case, does not actually reflect the error
      condition, and does not match the error code commonly returned by
      POSIX services for denoting a (temporary) lack of resources.
      Besides, this source of error was not even mentioned in the
      documentation of the affected services.
      
      All error codes must be detected, and any program that might have
      specifically checked for -ENOMEM during error recovery in the affected
      services was potentially confused, so this change does not introduce a
      significant ABI variation.
      364a91b4
  5. 17 Feb, 2015 1 commit
  6. 21 Sep, 2014 1 commit
  7. 09 Sep, 2014 2 commits
  8. 21 Aug, 2014 1 commit
  9. 15 Jun, 2014 1 commit
  10. 14 Jun, 2014 2 commits
  11. 12 Jun, 2014 1 commit
  12. 30 May, 2014 1 commit
    • Philippe Gerum's avatar
      cobalt: include headers explicitly when needed · 75d61004
      Philippe Gerum authored
      include/asm-generic/xenomai/wrappers.h was pulling in all sorts of
      unrelated header files, which have become useless as we dropped most
      wrappers.
      
      This caused a bunch of implementation files to rely on implicit
      inclusion of some common kernel headers, which is wrong. Fix this.
      75d61004
  13. 29 Apr, 2014 1 commit
  14. 16 Apr, 2014 1 commit
  15. 20 Feb, 2014 4 commits
  16. 19 Feb, 2014 1 commit
  17. 29 Dec, 2013 1 commit
  18. 20 Dec, 2013 1 commit
  19. 15 Dec, 2013 2 commits
  20. 10 Aug, 2013 5 commits
    • Philippe Gerum's avatar
    • Philippe Gerum's avatar
      cobalt/registry: drop debug knob · 907ff69e
      Philippe Gerum authored
      We don't get any useful information from the registry-specific debug
      messages these days.
      907ff69e
    • 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/pod: drop PEXEC and FATAL condition bits · 53b3bc6d
      Philippe Gerum authored
      XNPEXEC makes no sense anymore as it used to protect our kernel
      handlers from running when no real-time services are available yet.
      
      It turns out that the Cobalt core is now initialized early, and those
      handlers are not even installed until the interrupt pipeline is
      requested to forward the trap and syscall events, which only
      happens...after the system has been initialized.
      
      Finally, exposing the fatal bit as a global state flag, only to test
      it within the panic handler was quite overkill.
      53b3bc6d
    • 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
  21. 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
  22. 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
  23. 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
  24. 12 Jun, 2013 2 commits
    • Philippe Gerum's avatar
      cobalt: introduce interface personalities · 07703e73
      Philippe Gerum authored
      Personalities are service interfaces exposed by the Xenomai
      kernel. Personalities may or may not provide a particular system call
      interface to userland. However, they do allow userland processes to
      bind to them via the built-in sc_nucleus_bind syscall, for attaching a
      process.
      
      Therefore, personalities are useful for exporting a complete set of
      additional kernel services, and/or (solely) providing process resource
      management via the ppd mechanism.
      
      Unlike skins, personalities live in kernel space
      exclusively. Therefore, they are not aimed at implementing RTOS
      emulators which should live in userland, on top of the Copperplate
      emulation system. Instead, Xenomai personalities implement:
      
      - core Xenomai interfaces, such as Cobalt and RTDM.
      
      - extensions to the Cobalt API, by mean of a RTDM driver which should
        belong to the RTDM_CLASS_COBALT class.
      07703e73
    • Philippe Gerum's avatar
      bdf1e6d7
  25. 20 Dec, 2012 1 commit
  26. 28 Jan, 2012 3 commits
    • Philippe Gerum's avatar
      cobalt, drivers: reduce wrapping to host memory allocators · b419a78d
      Philippe Gerum authored
      Small/medium memory chunks (up to 128k) can be obtained from kmalloc()
      directly, for all the architectures we support.
      
      For the time being, we allocate potentially larger chunks from
      alloc_pages_exact() through the new xnarch_alloc_pages() generic
      wrapper, which gives us physically contiguous memory.
      b419a78d
    • Philippe Gerum's avatar
      cobalt: remove support for simulator · 42e896a8
      Philippe Gerum authored
      The venerable Xenomai simulator has been unmaintained for many moons,
      and there is no sign of change in this area.
      
      We remove the simulator pseudo-target from the tree, because it tends
      to get in the way of upcoming cleanups, and very unfortunately, it
      serves no purpose anymore.
      42e896a8
    • Philippe Gerum's avatar
      cobalt: globally rename pse51 -> cobalt · 58fe60b0
      Philippe Gerum authored
      58fe60b0