On Tue, Oct 6, 2020 at 2:30 AM Sebastian Huber < sebastian.hu...@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. 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 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. --joel > _______________________________________________ > 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
