Experimental Physics and
Industrial Control System

Chris Johns via Core-talk <core-talk at aps.anl.gov> · Tue, 9 Mar 2021 09:49:48 +1100

Hi,

I am sorry if I am a little late to this discussion.

On 4/3/21 9:07 am, Vijay Kumar Banerjee via Core-talk wrote:
> Hello Michael,
> 
> On Wed, Mar 3, 2021 at 1:50 PM Michael Davidsaver <mdavidsaver at gmail.com> wrote:
>>
>> On 3/1/21 2:43 PM, Vijay Kumar Banerjee via Core-talk wrote:
>>> Hello all,
>>>
>>> In RTEMS 6, there will be no cpukit/libnetworking in the RTEMS
>>> repository and it will be moved to its own separate repository. There
>>> are ongoing efforts in this direction and it is very close to
>>> completion. What's remaining, is to collect feedback from the users of
>>> the libnetworking stack.
>>
>> How will this change be reflected through the rtems-source-builder script?
>>
>> My current recipe for building with the legacy stack is eg.:
>>
>>> ../source-builder/sb-set-builder --prefix=/opt/rtems/5 --log build.log \
>>>   --host=powerpc-rtems5 --target=powerpc-rtems5 \
>>>   --with-rtems-bsp=mvme3100 --with-rtems-legacy-network 5/rtems-kernel
>>
> For this, my solution is that I have planned to work on the rtems
> source builder script and add a recipe for building the legacy stack.
> This means that if you have scripts that run the source-builder
> commands, they'll need to be updated to add another line for building
> the legacy stack. I can explore the possibility of triggering the
> legacy stack build recipe with an option like
> --whith-rtems-legacy-network. That might need no or fewer changes in
> your build scripts, but I'm not sure about how that'll turn out.

The stacks are considered separate packages and I hope they can be built
independently and installed side by side under the BSP. From an RTEMS
perspective if a stack (or any 3rd party package) can be built I would prefer
that happens so users can select which ever stack they want using options or
configurations they have control over.

>> Also, is this going the effect our current strategy of using the
>> RTEMS_HAS_NETWORKING macro?  Or, can you suggest another way to
>> programmatically identify which network stack is present?
>>
> This is an interesting question and I don't have a very straight
> answer. The RTEMS_HAS_NETWORKING option will be removed along with the
> relocation patches and it will not be. A not-so-clean solution that I
> can think of is to add a check in the legacy-net stack waf, so that it
> builds only when there's no libbsd present. Doing this from the RTEMS
> won't be very clean as RTEMS needs to be built before any networking
> stack.
> 
> Another solution that I can think of is to add a common config file in
> the build directory, which gets overwritten by whichever network stack
> is built. So if libbsd is built, it'll overwrite the file to indicate
> that libbsd stack is present. This can be clubbed together with a
> warning from waf.
> 
> Thoughts/suggestions?

Can the EPICS build system check the BSP to see which libraries are present and
then decide which stack to use? The libbsd library is libbsd.a and I am not sure
what the net-legacy archive name is.

Chris

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System