Am 02.08.2016 um 04:09 schrieb Chris Johns:
> On 02/08/2016 00:04, Christian Mauderer wrote:
>> Hello,
>>
>> we have a special use case where we want to use the new network stack
>> but without the IPv6 support. I could need some advice how this could be
>> integrated into the waf build system. If we find a good solution, this
>> could also be an example for other BSD Kernel options.
>>
>>
>> I found multiple places where IPv6 is enabled in libbsd:
>>
>> If I remove the INET6 option out of the FreeBSD kernel configuration on
>> a FreeBSD system, this has the effect, that the "opt_inet6.h" is
>> generated as an empty file instead of with a single define "#define
>> INET6 1". In the rtems-libbsd the configuration header is located at
>> rtemsbsd/include/rtems/bsd/local/opt_inet6.h. It has a fixed content
>> with the define set. This would be the first place where the support
>> would have to be disabled.
>>
>> Beneath that, some user space tools have a special option to enable IPv6
>> which is currently set in libbsd.py. One such example is tcpdump with a
>> compiler flag '-DINET6' set. As far as I could tell, the kernel and
>> every application that is included in libbsd currently uses the INET6
>> macro. But I think this is more of a convention than a general rule.
>>
>
> What about 'dhcpcd/ipv6.c' in the dhcpcd module? I think the problem may
> be a little more complicated and you may need to control the code being
> built based on the selected configuration.
>
I totally missed that. Thanks for the hint.
>>
>> So I think we would roughly need the following:
>>
>> If i configure libbsd using
>>
>> waf configure --disable-ipv6
>>
>
> I would prefer something like --config="networking:ipv6=no,..;" so a
> general interface can be added. I doubt this will be the last option
> that needs to be added. This avoids growing a long list of
> enable/disable options being used to add features. It also allows us to
> implement a generic framework we can use use in different areas where
> this may also need to happen, eg --config="usb:...;".
>
> If you consider the interface as a list of 'name=value' pairs it can be
> mapped to the INI format file which Python can read via the
> ConfigParser. This means:
>
> [networking]
> ipv6=no
>
> [udb]
> ...
>
> In time we could allow reading of these setting from a user defined
> configuration file, eg --config='file:myconfig.ini'.
>
I agree. I'll try to use this format.
>> the build system would either have to regenerate opt_inet6.h or use an
>> alternative version of it. Further I would need the ability to set
>> compiler flags in libbsd.py depending on this configure option.
>
> You could provide -DRTEMS_LIBBSD_INET6=1 and that would conditionally
> control '#define INET6 1' in 'opt_inet6.h'. I would prefer something
> static to generating files.
>
I'm OK with that. I just wouldn't have liked it to set a -DINET6 for
everything. It is a quite generic name that might be used for something
else at some places.
>> Are there any better ideas how to implement such an option?
>
> There are 2 parts that need be to changed to make this work. This
> assumes you will need to control the source being built.
>
> The first is the module descriptions in libbsd.py and then the
> generator. I suggest you look at the various module class methods used
> to add source and consider adding a 'section' argument which defaults to
> 'default' (always True). This would lets you move code into specific
> sections, for example:
>
> dhcpcd_defines='-D__FreeBSD__ -DTHERE_IS_NO_FORK ...'
> mod.addSourceFiles(
> [
> 'dhcpcd/ipv6.c',
> 'dhcpcd/ipv6nd.c',
> ],
> mm.generator['source'](dhcpcd_defines),
> section = 'networking.ipv6_yes'
> )
>
> Note, this definition generates something that is evaluated when waf
> runs so the 'section' populates a dict where the 'networking.ipv6_yes'
> key is tested for True or False depending what the user specifies.
>
> You could also change the class constructor so you have:
>
> mod = builder.Module('dhcpcd', section = 'networking.dhcp')
>
> The dot notation would allow control of the sources at the module level
> to finally get sorted out. The dhcpcd module becomes 'networking.dhcpcd'
> which means build if networking and dhcpcd are True. You could work down
> the dots checking at each point to make sure the module can be built.
> Currently module level user control has been left hanging with commented
> modules, eg '#mm.addModule(dev_usb_controller_add_on(mm)'. If the
> section 'usb.dev_usb_controller_add_on' is False by default that module
> is not built which is what we have now.
>
> The second part is in the waf script (wscript) which handles the user
> interface, ie parses
> --config="networking:ipv6=no,pink-frames-only,chrismac-buf-frames=64". I
> would add this code in a new Python module libbsd_opts.py and imported
> into libbsd_waf.py (generated) and called in the 'options' function in
> libbsd_waf.py. This would parse and populate a dict the generated module
> code uses.
>
Thanks for the detailed description. I'll need some time to understand
everything but it looks like a good starting point.
>> I'm quite inexperienced on how to use waf, so I would need some guidance
>> how this could be implemented. Are there any hints how I could start
>> implementing such an option? Some examples or similar code?
>
> There is nothing similar as the core of the functionality is in
> freebsd-to-rtems.py and related code which has been an on going
> development. Conditionally adding source can be seen in the generated
> waf script where archs are being tested.
I've feared that. I just hoped there was something that I've overlooked.
>
> I hope this helps.
>
It definitely does. Thank you.
> Chris
>
Kind regards,
Christian
--
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
