On 7/10/20 12:26 am, Joel Sherrill wrote: > On Tue, Oct 6, 2020 at 2:30 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto: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.
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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
