Re: libbsd: How to add an option for switching off IPv6 (or other BSD Kernel configurations)
Am 02.08.2016 um 08:57 schrieb Christian Mauderer:
> Am 02.08.2016 um 04:09 schrieb Chris Johns:
>> On 02/08/2016 00:04, Christian Mauderer wrote:
[...]
>
>>> 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.
>
[...]
>
Hello Chris,
I think I managed to understand most of it even if I still only have a
rough Idea where to start.
If I'm right, you suggested two alternative possible methods:
1) Add the section-option as parameter to a addSourceFiles. This means
it is only valid for some sources in a module.
2) Alternatively add it directly to the module.
Did I understand you correct. Or did you mean that the section is added
to both - the module and the source?
As far as I understand the first method, this could be also used for the
define that depends on the option. Something like this:
def dhcpcd(mm):
mod = builder.Module('dhcpcd')
dhcpcd_sources =
[
'dhcpcd/arp.c',
'dhcpcd/auth.c',
...
]
dhcpcd_defines_base = '-D__FreeBSD__ -DTHERE_IS_NO_FORK ...'
dhcpcd_defines_inet6 = dhcpcd_defines_base + ' -DINET6'
mod.addSourceFiles(
dhcpcd_sources,
mm.generator['source'](dhcpcd_defines_base),
section = 'networking.ipv6_no'
)
mod.addSourceFiles(
dhcpcd_sources,
mm.generator['source'](dhcpcd_defines_inet6),
section = 'networking.ipv6_yes'
)
return mod
I'm not sure how this would be possible with the second method.
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
Re: libbsd: How to add an option for switching off IPv6 (or other BSD Kernel configurations)
On 2/08/2016 8:05 PM, Christian Mauderer wrote:
> Am 02.08.2016 um 08:57 schrieb Christian Mauderer:
>> Am 02.08.2016 um 04:09 schrieb Chris Johns:
>>> On 02/08/2016 00:04, Christian Mauderer wrote:
> [...]
>>
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.
>>
> [...]
>>
>
> Hello Chris,
>
> I think I managed to understand most of it even if I still only have a
> rough Idea where to start.
>
> If I'm right, you suggested two alternative possible methods:
>
> 1) Add the section-option as parameter to a addSourceFiles. This means
> it is only valid for some sources in a module.
>
> 2) Alternatively add it directly to the module.
>
I am saying have both so all modules are provide a section.
I only used the work section because it is the term used in INI files.
> Did I understand you correct. Or did you mean that the section is added
> to both - the module and the source?
Close, but how about annotating all source and then we can control it
better.
>
> As far as I understand the first method, this could be also used for the
> define that depends on the option. Something like this:
>
> def dhcpcd(mm):
> mod = builder.Module('dhcpcd')
> dhcpcd_sources =
> [
> 'dhcpcd/arp.c',
> 'dhcpcd/auth.c',
> ...
> ]
> dhcpcd_defines_base = '-D__FreeBSD__ -DTHERE_IS_NO_FORK ...'
> dhcpcd_defines_inet6 = dhcpcd_defines_base + ' -DINET6'
> mod.addSourceFiles(
> dhcpcd_sources,
> mm.generator['source'](dhcpcd_defines_base),
> section = 'networking.ipv6_no'
> )
> mod.addSourceFiles(
> dhcpcd_sources,
> mm.generator['source'](dhcpcd_defines_inet6),
> section = 'networking.ipv6_yes'
> )
> return mod
>
It is close, however I suspect -DINET6 is need for all source when being
built. I will take a look and see what I can sort out.
> I'm not sure how this would be possible with the second method.
Let me take a closer look.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Add FreeBSD PF Firewall to libbsd
Hello, I've been working on a port of the FreeBSD firewall PF to libbsd. The first results are available in the libbsd HEAD (commits b5db3321b5b22 to f1941b2b828e). The patch set introduced the following new features: - A basic support for the FreeBSD cdev subsystem. This subsystem uses devfs which I implementation based on the RTEMS IMFS. - The PF modules can now be linked by using the SYSINIT_NEED_FIREWALL_PF and SYSINIT_NEED_FIREWALL_PFLOG configuration macros. - I ported the control tool for the firewall (pfctl) to libbsd. - I added a chapter on how to use PF to libbsd.txt. An example can be found in the pf01 test. - The method that I used for the pfctl port slightly improves the approach that is currently used for most other user space tools. A basic guide how to port a tool using the new method can be found in the libbsd.txt in the chapter "Porting of user space utilities". Basically I made two changes to the current approach: 1. I used a new method to handle the global variables. Basically they are put into a linker section that is saved before the program call and restored afterwards. 2. Beneath that I added some wrappers to calls like open / close or malloc / free. These wrappers create a list of opened files and allocated resources. After the program main function has finished, the resources are closed / freed. Please note: The method described in 1. makes it necessary to pull function static variables out of their functions. This works but is not really an optimal solution. The FreeBSD people are not really happy with this kind of patches. Currently I'm trying to evaluate an alternative solution (manipulating the object files to put the variables into a section) in this thread: https://lists.rtems.org/pipermail/devel/2016-August/015749.html Kind regards Christian Mauderer -- 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
Re: Error in initializing network parameters
The USB enumeration runs after the BSD initialization in its own threads. Thus, you have to wait a bit before you attempt to use this interface. You could use a routing socket to do this event triggered, see dhcpcd for an example. On 02/08/16 14:17, Deval Shah wrote: Hello all, With the USB and Ethernet working, I started running other tests like ping01 on raspberry Pi. I am getting following error while running the PING test. -- *** LIBBSD PING 1 TEST *** nexus0: bcm283x_dwcotg0: on nexus0 usbus0 on bcm283x_dwcotg0 usbus0: 480Mbps High Speed USB v2.0 uhub0: on usbus0 ifconfig: interface ue0 does not exist assertion "exit_code == EX_OK" failed: file "/home/gadgetman/development/rtems/rtems-libbsd/testsuite/include/rtems/bsd/test/default-network-init.h", line 125, function: default_network_ifconfig_hwif0 -- In general boot-log, like in init test, after detecting the "uhub0" device it detects "uhub1" device, which is the usb_ethernet controller. And after that the Ethernet interface "ue0" exists. -- *** LIBBSD INIT 1 TEST *** nexus0: bcm283x_dwcotg0: on nexus0 usbus0 on bcm283x_dwcotg0 usbus0: 480Mbps High Speed USB v2.0 uhub0: on usbus0 Sleeping to see what happens uhub0: 1 port with 1 removable, self powered uhub1: 2> on usbus0 uhub1: MTT enabled uhub1: 5 ports with 4 removable, self powered smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: 5a:ee:60:74:67:92 -- I believe the default-network-init.h tries to access the ethernet interface before it is created and the problem arises. I tried moving bsp/nexus-devices.h before rtems/bsd/test/default-network-init.h, but the problem remains the same. Any pointers ? Regards, Deval Shah ᐧ -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de 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
Error in initializing network parameters
Hello all, With the USB and Ethernet working, I started running other tests like ping01 on raspberry Pi. I am getting following error while running the PING test. -- *** LIBBSD PING 1 TEST *** nexus0: bcm283x_dwcotg0: on nexus0 usbus0 on bcm283x_dwcotg0 usbus0: 480Mbps High Speed USB v2.0 uhub0: on usbus0 ifconfig: interface ue0 does not exist assertion "exit_code == EX_OK" failed: file "/home/gadgetman/development/rtems/rtems-libbsd/testsuite/include/rtems/bsd/test/default-network-init.h", line 125, function: default_network_ifconfig_hwif0 -- In general boot-log, like in init test, after detecting the "uhub0" device it detects "uhub1" device, which is the usb_ethernet controller. And after that the Ethernet interface "ue0" exists. -- *** LIBBSD INIT 1 TEST *** nexus0: bcm283x_dwcotg0: on nexus0 usbus0 on bcm283x_dwcotg0 usbus0: 480Mbps High Speed USB v2.0 uhub0: on usbus0 Sleeping to see what happens uhub0: 1 port with 1 removable, self powered uhub1: on usbus0 uhub1: MTT enabled uhub1: 5 ports with 4 removable, self powered smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: 5a:ee:60:74:67:92 -- I believe the default-network-init.h tries to access the ethernet interface before it is created and the problem arises. I tried moving bsp/nexus-devices.h before rtems/bsd/test/default-network-init.h, but the problem remains the same. Any pointers ? Regards, Deval Shah ᐧ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd: Manipulating object files using waf build system
On Tue, Aug 2, 2016 at 2:04 AM, Christian Mauderer wrote: > Hello, > > I have a second waf problem beneath the one already discussed in the > other thread: Is it possible to do some object file manipulation before > linking? To be exact I would need to rename some of the sections in the > object files. > This might be one for a waf expert. I would try something like how IDL files are twice-processed https://waf.io/book/#_mixing_extensions_and_c_c_features We had to do something like that to get the FilesystemImage generated, e.g. examples-v2.git/filesystem/fat_ramdisk/wscript. But I don't know if this is applicable to object files, since those have to be created first. You might be able to define a custom task to deal with .o files, or define a custom "link_task". > > If you want to stop reading, you can do it here. The following is only > some background Information why this is necessary: > > Currently I'm porting the user space tool pfctl to set up the firewall > pf to libbsd. For all initialized (zero or value) global or static > variables I basically use the following method: > > - put all variables into one named linker section > - save the section before calling the main > - restore the section after calling main > > I'll add a more detailed description for the method that I used to port > into the libbsd.txt as soon as I'm finished with the work. > > > I have made some changes that I was trying to upstream to FreeBSD. The > changes are quite similar to the ones for other programs: > > - Make const what can be const. > - Make global variables static if possible. > - Move some static variables out of function scope. > > I've suggested these changes on the FreeBSD mailing list here: > > https://lists.freebsd.org/pipermail/freebsd-hackers/2016-July/049772.html > > The last one (moving the static variables out of the functions) was > necessary so I could easily add an attribute to the variables. Due to > the fact that it is not really an improvement, it has started some > discussion: > > https://lists.freebsd.org/pipermail/freebsd-hackers/2016-August/049821.html > > The method described there would not work for us. But we should be able > to rename some of the sections. Compared to my current method (adding an > attribute to every variable) this would make it simpler to update to a > newer version with some changed global variables. So it's worth a try. > > Kind regards, > > Christian Mauderer > > -- > > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Integration of libcoap into RTEMS-libbsd
Dear users, I would like to know if it is possible to integrate the POSIX/C CoAP implementation *libcoap *into RTEMS-libbsd. Do you think it is possible for now ? Do you have an idea on how to do this ? Any help could be great ! Kind Regards -- Babacar Diop 24 years Engineering student in Electronics and Computer Sciences of Embedded Systems at Polytech' Paris-UPMC 5th Year ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] rtems: add sys/mman.h
This mman.h is copied verbatim from the upstream freebsd sources pulled from the freebsd-org submodule used by rtems for the rtems-libbsd project: https://git.rtems.org/rtems-libbsd/tree/ On Mon, Aug 1, 2016 at 3:55 PM, Gedare Bloom wrote: > --- > newlib/libc/sys/rtems/include/sys/mman.h | 263 > +++ > 1 file changed, 263 insertions(+) > create mode 100644 newlib/libc/sys/rtems/include/sys/mman.h > > diff --git a/newlib/libc/sys/rtems/include/sys/mman.h > b/newlib/libc/sys/rtems/include/sys/mman.h > new file mode 100644 > index 000..e7e5cf4 > --- /dev/null > +++ b/newlib/libc/sys/rtems/include/sys/mman.h > @@ -0,0 +1,263 @@ > +/*- > + * Copyright (c) 1982, 1986, 1993 > + * The Regents of the University of California. All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * 4. Neither the name of the University nor the names of its contributors > + *may be used to endorse or promote products derived from this software > + *without specific prior written permission. > + * > + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + * > + * @(#)mman.h 8.2 (Berkeley) 1/9/95 > + * $FreeBSD$ > + */ > + > +#ifndef _SYS_MMAN_H_ > +#define _SYS_MMAN_H_ > + > +#include > +#include > + > +#if __BSD_VISIBLE > +/* > + * Inheritance for minherit() > + */ > +#define INHERIT_SHARE 0 > +#define INHERIT_COPY 1 > +#define INHERIT_NONE 2 > +#endif > + > +/* > + * Protections are chosen from these bits, or-ed together > + */ > +#definePROT_NONE 0x00/* no permissions */ > +#definePROT_READ 0x01/* pages can be read */ > +#definePROT_WRITE 0x02/* pages can be written */ > +#definePROT_EXEC 0x04/* pages can be executed */ > + > +/* > + * Flags contain sharing type and options. > + * Sharing types; choose one. > + */ > +#defineMAP_SHARED 0x0001 /* share changes */ > +#defineMAP_PRIVATE 0x0002 /* changes are private */ > +#if __BSD_VISIBLE > +#defineMAP_COPYMAP_PRIVATE /* Obsolete */ > +#endif > + > +/* > + * Other flags > + */ > +#defineMAP_FIXED0x0010 /* map addr must be exactly as > requested */ > + > +#if __BSD_VISIBLE > +#defineMAP_RENAME 0x0020 /* Sun: rename private pages to file > */ > +#defineMAP_NORESERVE0x0040 /* Sun: don't reserve needed swap > area */ > +#defineMAP_RESERVED0080 0x0080 /* previously misimplemented > MAP_INHERIT */ > +#defineMAP_RESERVED0100 0x0100 /* previously unimplemented > MAP_NOEXTEND */ > +#defineMAP_HASSEMAPHORE 0x0200 /* region may contain semaphores */ > +#defineMAP_STACK0x0400 /* region grows down, like a stack */ > +#defineMAP_NOSYNC 0x0800 /* page to but do not sync underlying > file */ > + > +/* > + * Mapping type > + */ > +#defineMAP_FILE 0x /* map from file (default) */ > +#defineMAP_ANON 0x1000 /* allocated from memory, swap space > */ > +#ifndef _KERNEL > +#defineMAP_ANONYMOUSMAP_ANON /* For compatibility. */ > +#endif /* !_KERNEL */ > + > +/* > + * Extended flags > + */ > +#defineMAP_NOCORE 0x0002 /* dont include these pages in a > coredump */ > +#defineMAP_PREFAULT_READ 0x0004 /* prefault mapping for reading > */ > + > +/* > + * Request specific alignment (n == log2 of the desired alignment). > + * > + * MAP_ALIGNED_SUPER requests optimal superpage alignment, but does > + * not enforce a specific alignment. > + */ > +#defineMAP_ALIGNED(n) ((n) << MAP_ALIGNMENT_SHIFT) > +#defineMAP_ALIGNMENT_SHIFT 24 > +#defineMAP_ALIGNMENT_MASK MAP_ALIGNED(
Re: [PATCH] posix: move sys/mman.h to newlib and test it in psxhdrs
This patch can wait until the tool chain patch is available in a snapshot. On Mon, Aug 1, 2016 at 8:48 PM, Chris Johns wrote: > On 02/08/2016 06:12, Gedare Bloom wrote: >> >> This requires toolchain bump with the sister patch "rtems: add >> sys/mman.h" on newlib. > > > What is the plan to get this patch merged? > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Integration of libcoap into RTEMS-libbsd
On Tue, Aug 2, 2016 at 11:05 AM, Babacar Diop wrote: > Dear users, > > I would like to know if it is possible to integrate the POSIX/C CoAP > implementation libcoap into RTEMS-libbsd. > Should be possible to link it with an RTEMS built with libbsd using the POSIX interfaces in CoAP. > Do you think it is possible for now ? Do you have an idea on how to do this > ? > First you would need to build/install RTEMS with a networking stack and test that you have networking capabilities working out-of-the-box. Then you would have to figure out how to make the build system for CoAP compile and link against your built RTEMS, or write your own build scripts. Oh, and you should build it as a static library. Then it should be possible to compile/link an example using the installed RTEMS and linking to the static coap library. > Any help could be great ! > > > Kind Regards > > > -- > > Babacar Diop > 24 years > Engineering student in Electronics and Computer Sciences of Embedded Systems > at Polytech' Paris-UPMC > 5th Year > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Integration of libcoap into RTEMS-libbsd
Dear Gedare, Thank you for response. I forgot to precise that I have the networking capabilities on my beaglebone black thanks to Ragunath's work. Ok so basically, I thought about using the RSB to add the library into RTEMS as a static library as it might help me to automatize the work. Is it really necessary to build my own script or does the curernt RSB can do the work with my custom configuration ? Kind Regards 2016-08-02 16:38 GMT+01:00 Gedare Bloom : > On Tue, Aug 2, 2016 at 11:05 AM, Babacar Diop wrote: > > Dear users, > > > > I would like to know if it is possible to integrate the POSIX/C CoAP > > implementation libcoap into RTEMS-libbsd. > > > Should be possible to link it with an RTEMS built with libbsd using > the POSIX interfaces in CoAP. > > > Do you think it is possible for now ? Do you have an idea on how to do > this > > ? > > > First you would need to build/install RTEMS with a networking stack > and test that you have networking capabilities working out-of-the-box. > Then you would have to figure out how to make the build system for > CoAP compile and link against your built RTEMS, or write your own > build scripts. Oh, and you should build it as a static library. Then > it should be possible to compile/link an example using the installed > RTEMS and linking to the static coap library. > > > Any help could be great ! > > > > > > Kind Regards > > > > > > > -- > > > > Babacar Diop > > 24 years > > Engineering student in Electronics and Computer Sciences of Embedded > Systems > > at Polytech' Paris-UPMC > > 5th Year > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > -- Babacar Diop 23 ans Élève ingénieur à Polytech' Paris-UPMC Section Électronique, Informatique des Systèmes Embarqués Année 5 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Integration of libcoap into RTEMS-libbsd
On Tue, Aug 2, 2016 at 11:53 AM, Babacar Diop wrote: > Dear Gedare, > > Thank you for response. I forgot to precise that I have the networking > capabilities on my beaglebone black thanks to Ragunath's work. > > Ok so basically, I thought about using the RSB to add the library into RTEMS > as a static library as it might help me to automatize > the work. Is it really necessary to build my own script or does the curernt > RSB can do the work with my custom configuration ? > RSB won't know how to build the library. You have to teach it, see for examples: https://git.rtems.org/rtems-source-builder/tree/rtems/config/graphics You should first be able to manually build the library and validate that it works for you. then you can provide the RSB script for easier maintenance and to share with the world. > Kind Regards > > 2016-08-02 16:38 GMT+01:00 Gedare Bloom : >> >> On Tue, Aug 2, 2016 at 11:05 AM, Babacar Diop wrote: >> > Dear users, >> > >> > I would like to know if it is possible to integrate the POSIX/C CoAP >> > implementation libcoap into RTEMS-libbsd. >> > >> Should be possible to link it with an RTEMS built with libbsd using >> the POSIX interfaces in CoAP. >> >> > Do you think it is possible for now ? Do you have an idea on how to do >> > this >> > ? >> > >> First you would need to build/install RTEMS with a networking stack >> and test that you have networking capabilities working out-of-the-box. >> Then you would have to figure out how to make the build system for >> CoAP compile and link against your built RTEMS, or write your own >> build scripts. Oh, and you should build it as a static library. Then >> it should be possible to compile/link an example using the installed >> RTEMS and linking to the static coap library. >> >> > Any help could be great ! >> > >> > >> > Kind Regards >> > >> > >> > >> > -- >> > >> > Babacar Diop >> > 24 years >> > Engineering student in Electronics and Computer Sciences of Embedded >> > Systems >> > at Polytech' Paris-UPMC >> > 5th Year >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel > > > > > -- > > > Babacar Diop > 23 ans > Élève ingénieur à Polytech' Paris-UPMC > Section Électronique, Informatique des Systèmes Embarqués > Année 5 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] pfctl: Adapt for RTEMS.
On 02/08/2016 21:21, Sebastian Huber wrote: freebsd/contrib/pf/pfctl/parse-data.h | 42 diff --git a/freebsd/contrib/pf/pfctl/parse-data.h b/freebsd/contrib/pf/pfctl/parse-data.h new file mode 100644 index 000..22f6295 --- /dev/null +++ b/freebsd/contrib/pf/pfctl/parse-data.h @@ -0,0 +1,42 @@ +#include + +RTEMS_LINKER_RWSET_CONTENT(bsd_prog_pfctl, +static struct antispoof_opts antispoof_opts); I am seeing ... [ 18/954] Compiling freebsd/contrib/pf/pfctl/pfctl_qstats.c In file included from ../../freebsd/contrib/pf/pfctl/parse.y:6138:0: ../../freebsd/contrib/pf/pfctl/parse-data.h:4:5: error: expected ')' before 'static' static struct antispoof_opts antispoof_opts); ^~ ../../freebsd/contrib/pf/pfctl/parse-data.h:5:44: error: expected ')' before 'static' RTEMS_LINKER_RWSET_CONTENT(bsd_prog_pfctl, static int blockpolicy); ^~ Are these changes OK? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add FreeBSD PF Firewall to libbsd
On 02/08/2016 21:27, Christian Mauderer wrote: - A basic support for the FreeBSD cdev subsystem. This subsystem uses devfs which I implementation based on the RTEMS IMFS. Is this automatically included and what can we configure and control? - The PF modules can now be linked by using the SYSINIT_NEED_FIREWALL_PF and SYSINIT_NEED_FIREWALL_PFLOG configuration macros. Can you please add RTEMS_BSD_CONFIG_FIREWALL_PF and RTEMS_BSD_CONFIG_FIREWALL_PFLOG to rtems-bsd-config.h. This is the user interface and what I intend to document and so what we need to maintain and keep working into the future. - I ported the control tool for the firewall (pfctl) to libbsd. - I added a chapter on how to use PF to libbsd.txt. An example can be found in the pf01 test. Is there support for rc.conf(5) (https://www.freebsd.org/cgi/man.cgi?rc.conf%285%29) in the change? It would be nice to support ipfilter_enable, ipfilter_rules, ipv6_ipfilter_rules, and ipfilter_flags. I think ipfilter_program can be silently ignored. I would like LibBSD's user interface to be rc.conf(5) as standard and my hope is the support work I have done for rc.conf makes it easy to add support. I am happy for other ways to configure to be present and the tests tend to need this however users who depend on those interface maybe disappointed if those interfaces change or break. - The method that I used for the pfctl port slightly improves the approach that is currently used for most other user space tools. A basic guide how to port a tool using the new method can be found in the libbsd.txt in the chapter "Porting of user space utilities". This is a nice change. Basically I made two changes to the current approach: 1. I used a new method to handle the global variables. Basically they are put into a linker section that is saved before the program call and restored afterwards. 2. Beneath that I added some wrappers to calls like open / close or malloc / free. These wrappers create a list of opened files and allocated resources. After the program main function has finished, the resources are closed / freed. Please note: The method described in 1. makes it necessary to pull function static variables out of their functions. This works but is not really an optimal solution. The FreeBSD people are not really happy with this kind of patches. Currently I'm trying to evaluate an alternative solution (manipulating the object files to put the variables into a section) in this thread: https://lists.rtems.org/pipermail/devel/2016-August/015749.html I have wondered about using libdl as a way to wrap and limit scope and while it is a nice idea ARM needs veneers to be fully supported. I have also wondered if a GCC plugin could be used when building these specific files to handle the linker attributes automatically. There is a nice Python plugin framework for GCC which may help make this easier. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] pfctl: Adapt for RTEMS.
On 03/08/16 01:22, Chris Johns wrote: On 02/08/2016 21:21, Sebastian Huber wrote: freebsd/contrib/pf/pfctl/parse-data.h | 42 diff --git a/freebsd/contrib/pf/pfctl/parse-data.h b/freebsd/contrib/pf/pfctl/parse-data.h new file mode 100644 index 000..22f6295 --- /dev/null +++ b/freebsd/contrib/pf/pfctl/parse-data.h @@ -0,0 +1,42 @@ +#include + +RTEMS_LINKER_RWSET_CONTENT(bsd_prog_pfctl, +static struct antispoof_opts antispoof_opts); I am seeing ... [ 18/954] Compiling freebsd/contrib/pf/pfctl/pfctl_qstats.c In file included from ../../freebsd/contrib/pf/pfctl/parse.y:6138:0: ../../freebsd/contrib/pf/pfctl/parse-data.h:4:5: error: expected ')' before 'static' static struct antispoof_opts antispoof_opts); ^~ ../../freebsd/contrib/pf/pfctl/parse-data.h:5:44: error: expected ')' before 'static' RTEMS_LINKER_RWSET_CONTENT(bsd_prog_pfctl, static int blockpolicy); ^~ Are these changes OK? Does it work after an RTEMS update? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de 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
Re: [PATCH] posix: move sys/mman.h to newlib and test it in psxhdrs
Maybe it makes sense to bundle this with a GCC 6.2 release tool chain update. On 02/08/16 16:23, Gedare Bloom wrote: This patch can wait until the tool chain patch is available in a snapshot. On Mon, Aug 1, 2016 at 8:48 PM, Chris Johns wrote: On 02/08/2016 06:12, Gedare Bloom wrote: This requires toolchain bump with the sister patch "rtems: add sys/mman.h" on newlib. What is the plan to get this patch merged? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de 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
Re: libbsd: Manipulating object files using waf build system
Am 02.08.2016 um 16:41 schrieb Gedare Bloom: > On Tue, Aug 2, 2016 at 2:04 AM, Christian Mauderer > wrote: >> Hello, >> >> I have a second waf problem beneath the one already discussed in the >> other thread: Is it possible to do some object file manipulation before >> linking? To be exact I would need to rename some of the sections in the >> object files. >> > This might be one for a waf expert. I would try something like how IDL > files are twice-processed > https://waf.io/book/#_mixing_extensions_and_c_c_features > > We had to do something like that to get the FilesystemImage generated, > e.g. examples-v2.git/filesystem/fat_ramdisk/wscript. > > But I don't know if this is applicable to object files, since those > have to be created first. You might be able to define a custom task to > deal with .o files, or define a custom "link_task". > Hello Gedare, thanks for the pointers. I'll take a look at them. 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
Re: Add FreeBSD PF Firewall to libbsd
Am 03.08.2016 um 02:54 schrieb Chris Johns: > On 02/08/2016 21:27, Christian Mauderer wrote: >> - A basic support for the FreeBSD cdev subsystem. This subsystem uses >> devfs which I implementation based on the RTEMS IMFS. > > Is this automatically included and what can we configure and control? A lot of drivers in BSD use the cdev subsystem to create their /dev/xyz nodes. Till now we had only a very minimalistic implementation (enough to let everything link without errors) and a lot of workarounds to somehow avoid the usage of the /dev/xyz nodes or to create them inside the driver. One such example is freebsd/sys/net/bpf.c My implementation replaces the "let me just link" version. Therefore it is automatically included like the previous version. I don't think that it would be useful to switch it off. Making it optional means that we would have to offer a selection between the old "let me just link" version and the new one. That could lead to a lot of problems with dependencies. Some drivers might would rely on the one or the other implementation. > >> - The PF modules can now be linked by using the SYSINIT_NEED_FIREWALL_PF >> and SYSINIT_NEED_FIREWALL_PFLOG configuration macros. > > Can you please add RTEMS_BSD_CONFIG_FIREWALL_PF and > RTEMS_BSD_CONFIG_FIREWALL_PFLOG to rtems-bsd-config.h. > > This is the user interface and what I intend to document and so what we > need to maintain and keep working into the future. > I'll look into this. >> - I ported the control tool for the firewall (pfctl) to libbsd. >> >> - I added a chapter on how to use PF to libbsd.txt. An example can be >> found in the pf01 test. > > Is there support for rc.conf(5) > (https://www.freebsd.org/cgi/man.cgi?rc.conf%285%29) in the change? > > It would be nice to support ipfilter_enable, ipfilter_rules, > ipv6_ipfilter_rules, and ipfilter_flags. I think ipfilter_program can be > silently ignored. > > I would like LibBSD's user interface to be rc.conf(5) as standard and my > hope is the support work I have done for rc.conf makes it easy to add > support. I am happy for other ways to configure to be present and the > tests tend to need this however users who depend on those interface > maybe disappointed if those interfaces change or break. > I haven't added the support. But I'll try to create a patch in the next few days. >> - The method that I used for the pfctl port slightly improves the >> approach that is currently used for most other user space tools. A basic >> guide how to port a tool using the new method can be found in the >> libbsd.txt in the chapter "Porting of user space utilities". > > This is a nice change. > >> >> Basically I made two changes to the current approach: >> >> 1. I used a new method to handle the global variables. Basically they >> are put into a linker section that is saved before the program call and >> restored afterwards. >> >> 2. Beneath that I added some wrappers to calls like open / close or >> malloc / free. These wrappers create a list of opened files and >> allocated resources. After the program main function has finished, the >> resources are closed / freed. >> >> Please note: The method described in 1. makes it necessary to pull >> function static variables out of their functions. This works but is not >> really an optimal solution. The FreeBSD people are not really happy with >> this kind of patches. Currently I'm trying to evaluate an alternative >> solution (manipulating the object files to put the variables into a >> section) in this thread: >> >> https://lists.rtems.org/pipermail/devel/2016-August/015749.html >> > > I have wondered about using libdl as a way to wrap and limit scope and > while it is a nice idea ARM needs veneers to be fully supported. I have > also wondered if a GCC plugin could be used when building these specific > files to handle the linker attributes automatically. There is a nice > Python plugin framework for GCC which may help make this easier. > I think libdl is currently only available for some platforms? So my suggested solution currently targets a wider range of plattforms without the necessity to first port libdl. The plugin could be a solution to automate the process. But It would be highly gcc specific. I think that manipulating the section names inside the object file like suggested in the linked discussion would be a more portable solution. 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
Re: Add FreeBSD PF Firewall to libbsd
On 03/08/2016 15:56, Christian Mauderer wrote: Am 03.08.2016 um 02:54 schrieb Chris Johns: On 02/08/2016 21:27, Christian Mauderer wrote: - A basic support for the FreeBSD cdev subsystem. This subsystem uses devfs which I implementation based on the RTEMS IMFS. Is this automatically included and what can we configure and control? A lot of drivers in BSD use the cdev subsystem to create their /dev/xyz nodes. Till now we had only a very minimalistic implementation (enough to let everything link without errors) and a lot of workarounds to somehow avoid the usage of the /dev/xyz nodes or to create them inside the driver. One such example is freebsd/sys/net/bpf.c My implementation replaces the "let me just link" version. Therefore it is automatically included like the previous version. I don't think that it would be useful to switch it off. I agree. This is a nice change to have. Making it optional means that we would have to offer a selection between the old "let me just link" version and the new one. That could lead to a lot of problems with dependencies. Some drivers might would rely on the one or the other implementation. I was only asking to see if there was something we need to manage. - The PF modules can now be linked by using the SYSINIT_NEED_FIREWALL_PF and SYSINIT_NEED_FIREWALL_PFLOG configuration macros. Can you please add RTEMS_BSD_CONFIG_FIREWALL_PF and RTEMS_BSD_CONFIG_FIREWALL_PFLOG to rtems-bsd-config.h. This is the user interface and what I intend to document and so what we need to maintain and keep working into the future. I'll look into this. Thanks. - I ported the control tool for the firewall (pfctl) to libbsd. - I added a chapter on how to use PF to libbsd.txt. An example can be found in the pf01 test. Is there support for rc.conf(5) (https://www.freebsd.org/cgi/man.cgi?rc.conf%285%29) in the change? It would be nice to support ipfilter_enable, ipfilter_rules, ipv6_ipfilter_rules, and ipfilter_flags. I think ipfilter_program can be silently ignored. I would like LibBSD's user interface to be rc.conf(5) as standard and my hope is the support work I have done for rc.conf makes it easy to add support. I am happy for other ways to configure to be present and the tests tend to need this however users who depend on those interface maybe disappointed if those interfaces change or break. I haven't added the support. But I'll try to create a patch in the next few days. Great. If there is something you need in the rc.conf support please let me know. - The method that I used for the pfctl port slightly improves the approach that is currently used for most other user space tools. A basic guide how to port a tool using the new method can be found in the libbsd.txt in the chapter "Porting of user space utilities". This is a nice change. Basically I made two changes to the current approach: 1. I used a new method to handle the global variables. Basically they are put into a linker section that is saved before the program call and restored afterwards. 2. Beneath that I added some wrappers to calls like open / close or malloc / free. These wrappers create a list of opened files and allocated resources. After the program main function has finished, the resources are closed / freed. Please note: The method described in 1. makes it necessary to pull function static variables out of their functions. This works but is not really an optimal solution. The FreeBSD people are not really happy with this kind of patches. Currently I'm trying to evaluate an alternative solution (manipulating the object files to put the variables into a section) in this thread: https://lists.rtems.org/pipermail/devel/2016-August/015749.html I have wondered about using libdl as a way to wrap and limit scope and while it is a nice idea ARM needs veneers to be fully supported. I have also wondered if a GCC plugin could be used when building these specific files to handle the linker attributes automatically. There is a nice Python plugin framework for GCC which may help make this easier. I think libdl is currently only available for some platforms? So my suggested solution currently targets a wider range of plattforms without the necessity to first port libdl. Yes and it complicates the build because of symbols and this extends the reach of what is needed into the user's build systems. The plugin could be a solution to automate the process. But It would be highly gcc specific. Yes. I think that manipulating the section names inside the object file like suggested in the linked discussion would be a more portable solution. I did not pick this up when I read the thread. What is being suggested? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add FreeBSD PF Firewall to libbsd
Am 03.08.2016 um 08:02 schrieb Chris Johns: > On 03/08/2016 15:56, Christian Mauderer wrote: >> Am 03.08.2016 um 02:54 schrieb Chris Johns: >>> On 02/08/2016 21:27, Christian Mauderer wrote: - A basic support for the FreeBSD cdev subsystem. This subsystem uses devfs which I implementation based on the RTEMS IMFS. >>> >>> Is this automatically included and what can we configure and control? >> >> A lot of drivers in BSD use the cdev subsystem to create their /dev/xyz >> nodes. Till now we had only a very minimalistic implementation (enough >> to let everything link without errors) and a lot of workarounds to >> somehow avoid the usage of the /dev/xyz nodes or to create them inside >> the driver. One such example is freebsd/sys/net/bpf.c >> >> My implementation replaces the "let me just link" version. Therefore it >> is automatically included like the previous version. I don't think that >> it would be useful to switch it off. > > I agree. This is a nice change to have. > >> Making it optional means that we would have to offer a selection between >> the old "let me just link" version and the new one. That could lead to a >> lot of problems with dependencies. Some drivers might would rely on the >> one or the other implementation. > > I was only asking to see if there was something we need to manage. > >> >>> - The PF modules can now be linked by using the SYSINIT_NEED_FIREWALL_PF and SYSINIT_NEED_FIREWALL_PFLOG configuration macros. >>> >>> Can you please add RTEMS_BSD_CONFIG_FIREWALL_PF and >>> RTEMS_BSD_CONFIG_FIREWALL_PFLOG to rtems-bsd-config.h. >>> >>> This is the user interface and what I intend to document and so what we >>> need to maintain and keep working into the future. >>> >> >> I'll look into this. >> > > Thanks. > - I ported the control tool for the firewall (pfctl) to libbsd. - I added a chapter on how to use PF to libbsd.txt. An example can be found in the pf01 test. >>> >>> Is there support for rc.conf(5) >>> (https://www.freebsd.org/cgi/man.cgi?rc.conf%285%29) in the change? >>> >>> It would be nice to support ipfilter_enable, ipfilter_rules, >>> ipv6_ipfilter_rules, and ipfilter_flags. I think ipfilter_program can be >>> silently ignored. >>> >>> I would like LibBSD's user interface to be rc.conf(5) as standard and my >>> hope is the support work I have done for rc.conf makes it easy to add >>> support. I am happy for other ways to configure to be present and the >>> tests tend to need this however users who depend on those interface >>> maybe disappointed if those interfaces change or break. >>> >> >> I haven't added the support. But I'll try to create a patch in the next >> few days. >> > > Great. If there is something you need in the rc.conf support please let > me know. > - The method that I used for the pfctl port slightly improves the approach that is currently used for most other user space tools. A basic guide how to port a tool using the new method can be found in the libbsd.txt in the chapter "Porting of user space utilities". >>> >>> This is a nice change. >>> Basically I made two changes to the current approach: 1. I used a new method to handle the global variables. Basically they are put into a linker section that is saved before the program call and restored afterwards. 2. Beneath that I added some wrappers to calls like open / close or malloc / free. These wrappers create a list of opened files and allocated resources. After the program main function has finished, the resources are closed / freed. Please note: The method described in 1. makes it necessary to pull function static variables out of their functions. This works but is not really an optimal solution. The FreeBSD people are not really happy with this kind of patches. Currently I'm trying to evaluate an alternative solution (manipulating the object files to put the variables into a section) in this thread: https://lists.rtems.org/pipermail/devel/2016-August/015749.html >>> >>> I have wondered about using libdl as a way to wrap and limit scope and >>> while it is a nice idea ARM needs veneers to be fully supported. I have >>> also wondered if a GCC plugin could be used when building these specific >>> files to handle the linker attributes automatically. There is a nice >>> Python plugin framework for GCC which may help make this easier. >>> >> >> I think libdl is currently only available for some platforms? So my >> suggested solution currently targets a wider range of plattforms without >> the necessity to first port libdl. > > Yes and it complicates the build because of symbols and this extends the > reach of what is needed into the user's build systems. > >> The plugin could be a solution to automate the process. But It would be >> highly gcc specific. > > Yes. > >> I think that manipulating the section names inside >> the
Re: Add FreeBSD PF Firewall to libbsd
On 03/08/2016 16:15, Christian Mauderer wrote: Basically it boils down to the following: Currently I use an __attribute__ on every variable that has to be initialized. That makes updates a little more difficult because we would have to look out for changed variables. In addition it is difficult for function static variables. Ok, this makes sense. A solution that would be simpler to maintain would be to manipulate the object file. I would use objcopy to rename all sections with initialized variables to put them into the linker set. This would be a little less obvious if you read only the c code but it would solve both problems mentioned above. Having transparent source is more important. But it makes it necessary that the build system adds the object file manipulation step before it links the application. That is the point where I'm currently stuck. Should I wait for this to happen before adding any new control logic to the build system? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
