[Xenomai-core] RTDM driver add-on infrastructure

[Xenomai-core] RTDM driver add-on infrastructure

[Wolfgang Grandegger]

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:

   $ 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?

Wolfgang.

Re: [Xenomai-core] RTDM driver add-on infrastructure

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

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?

> 
>   $ 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...)?


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).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Xenomai-core] RTDM driver add-on infrastructure

[Wolfgang Grandegger]

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.