Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,

I'm currently implementing a RTDM real-time CAN driver, which raises the
the problem of adding the driver to the Xenomai source tree. My first
idea was to provide RTCAN as a patch for Xenomai:

So you prefer to maintain RTCAN out-of-tree on the long term? What are
the reasons?

No, when the code is stable it can go to the Xenomai repository, like for the Linux kernel. It clearly simplifies maintenance , at least for the maintainer of the driver. Nevertheless, an Add-On facility would be nice to have.


  $ cd xenomai
  $ patch -p1 < xenomai-rtcan-add-on.patch
  $ scripts/prepare_kernel ...
  ...
  $ <configure and make kernel>
  $ <configure, make and install Xenomai user space stuff>

This does not work because of autoconf files needed to copy header files
to the installation path. Is this really necessary?
Another issue is where to put utility and test programs. Making them
without autoconf and friends works by using xeno-config. But they should
be installed with make install as well. Likely there are other issues.

Any ideas or comments on how to provide a generic RTDM driver add-on
infrastructure?

When you first talked about an "RTDM plugin" interface for Xenomai, I
got the idea of dragging external sources into the Xenomai kernel build
process. I haven't thought about this technically yet, but it would
allow to keep driver source packages maintained externally while still
providing them the option to become built into the kernel.

Ok, let's think about this for a while: We would need some management
script(s) to link an external source tree into the config and build
process, the remove it again, and probably to give a list of the
currently active plugins. Should be feasible without huge magic,
shouldn't it? But does this make sense, is it desirable (to me it is
when I think about making RTnet build cleanly against 2.6.17 yesterday...)?

Ala Xenomai's prepare_kernel script, which mainly adds links to the kernel tree and modifies some Makefiles and Kconfig (Config.in) files. Removing an Add-On seems not to be that important for me. This sounds reasonable.

Adding the RTCAN driver to Xenomai really solved a lot of build and installations issues without caring about the kernel version 2.4 or 2.6 :-).

This does not address your user mode utils, but I think they should
rather be distributed independently (something I have in mind for RTnet
as well once we ever switch from /dev/rtnet to some RTDM socket/device
for config work). The required rtdm/rtcan.h should be merged into
Xenomai, yet unmerged revisions could alternatively come with the
rtcan-utils packages to make it build (autoconf if your friend to detect
the available revision).

I think the Add-on package should provide both, the driver _and_ user-space utility and test programs.

Wolfgang.




_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to