[RTnet-developers] Re: [proposal] making use of module symbols

[Jan K. <ki...@rt...>]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Philippe Gerum wrote:
>>
>>> ...
>>> Good idea. Just implemented as described, now in the CVS. Thanks for the
>>> hint. Additional testing welcome.
>>>
>>> PS: *.mod files contents refer to the build directory, so I guess that
>>> such information would not be useful for setups that only provide the
>>> installed binaries (and not the initial build dir). But still, I have
>>> nonetheless exported the symbols to $exec_prefix/symbols as proposed.
>>>
>>
>>
>> That's good news. I started playing a bit with it and have two remarks
>> so far:
>>
>> 1. As it seems that we will no longer be able to build *modules* against
>> RTAI just by using the files from the installation directory, I see no
>
>
> Why? I mean, I don't see the difference wrt the previous situation. We
> can still build modules only using the installed stuff and the kernel
> tree in any case, we just get the Kbuild warnings unless we have the
> symbols available from the initial fusion build dir. I've just tried
> that after having removed the build dir, and it's ok.

I thought the PPC issues were severer than just warnings. Anyway,
reasonable development is not possible with all those warnings around
again, and that's what made me draw the line.

>
>> need anymore to actually install the symbol files. Creating a link, just
>> like "build", for "symbols" should be ok.
>>
>
> Agreed; as said earlier, the .mod files only contain pointers to the
> build dir anyway, so a symlink would be enough.
>
>> 2. Should external projects assume that the symbol dir is always
>> "symbols", or should rtai-config be extended to return it? I'm in no
>> favour for any of the options, I just would like to know which one to
>> implement.
>
>
> rtai-config --symbol-dir (for consistency reason, since we already have
> --module-dir).
>

The new concept has been adapted to RTnet now and is part of its SVN
repos. Anyone interested in autotool-based module builds against fusion
is invited to have a look and steal ideas.

Short description: RTnet creates a "symbols" dir in its build dir, then
links all files found in fusion's symbols dir to its own. Thus, all
*.mod files are gathered during the RTnet build aside those links in
RTnet's private symbols dir, and this one can easily be passed to the
kernel build command via MODVERDIR. On "make distclean", and that's an
extension fusion may want to gain as well, the *.mod files of the
respective module are removed from the central symbols dir again.

This model should even work when being extended by another indirection:
the eth-over-1394 driver of RTnet has to be built against the (external)
RT-FireWire project, which is also build against fusion of course. Now,
when providing that project dir via --with-rtfw, RTnet should rather
collect links and symbols from a (future) RT-FireWire symbols dir and
put them into its own. This would allow to stack projects respecting
their symbol dependencies.

Yuchen [RT-FireWire maintainer], if you are listening: you are likely
busy with other things right now, but we should keep this in mind and
check later if it is feasible.


Besides all this autotool stuff, here is a concept for "plain" external
module builds. For that purpose, I extended the GNUmakefile of rt_cifibm
(the recently published InterBus driver) as follows:

1. Introduced the variable

   SYMBOL_DIR = $(shell $(FUSIONDIR)/bin/rtai-config --symbol-dir)


2. Added

   MODVERDIR=$$PWD/symbols

   to the module make command and let it additionally depend on the
   target "symbols"


3. Added the target symbols

   symbols:
           @mkdir -p symbols
           @rm -rf symbols/*
           @for FILE in `ls $(SYMBOL_DIR)/*`; do \
               ln -s $$FILE symbols/`basename $$FILE`; \
           done


4. Cleaned up "symbols" on "make clean" (instead of ".tmp_versions")

A modified version of the driver package will be uploaded to my page soon.

Jan