Old network stack and aarch64

[Chris Johns]

On 7/10/20 12:26 am, Joel Sherrill wrote:
> On Tue, Oct 6, 2020 at 2:30 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> wrote:
> 
>     Hello,
> 
>     building the old network stack for aarch64 fails with:
> 
>     cpukit/librpc/src/xdr/xdr_float.c:121:2: error: #error "xdr_float.c:
>     unknown CPU"
>        121 | #error "xdr_float.c: unknown CPU"
> 
>     Should we enable RTEMS_NETWORKING more selectively similar to RTEMS_SMP
>     and RTEMS_MULTIPROCESSING?
> 
> 
> Yes for sure. In the autoconf system, we just excluded a few CPUs.

Yes

> But should we go farther in waf? I see two possibilities:
> 
> + Force legacy stack off for the same CPUs as autoconf build plus
>    all the BSPs that have new stack support.
> 
> + Only enable it for the specific BSPs that have HAS_NETWORKING
>    in their Makefile.am?  A quick grep shows 37 of 84 families would be
>    white listed this way. 

+ The --enable-networking and waf equivalent should indicate the option is
depreciated.

> The first is very easy. The second is a bit more painful but puts us on
> a path of identifying specifically what has to transition.
> 
> With a bit of discussion on the rules for being white listed to use the
> legacy stack, I would lean to the second solution.

What about users with private drivers in their code base? I know of zynq users
with such drivers.

Chris