[PATCH rtems-libbsd v2 3/4] rtemsbsd: Made TTCP command build for RTEMS

[Christian Mauderer]

On 15/06/2021 20:03, Joel Sherrill wrote:
> 
> 
> On Tue, Jun 15, 2021 at 10:25 AM Gedare Bloom <gedare at rtems.org 
> <mailto:gedare at rtems.org>> wrote:
> 
>     On Fri, Jun 11, 2021 at 11:19 AM Stephen Clark
>     <stephen.clark at oarcorp.com <mailto:stephen.clark at oarcorp.com>> wrote:
>      >
>      > Updated ttcp.c to build for RTEMS 6, in addition to the machines
>      > it originally built for. Also fixed ttcp.c to close network sockets
>      > after completion. Defined a shell command for TTCP in
>      > rtems-bsd-shell-ttcp.c. Added TTCP to the list of RTEMS network
>      > commands in netcmds-config.h. Added declaration of the TTCP shell
>      > command to rtems-bsd-commands.h. Modified libbsd.py to make waf
>      > build TTCP and its shell command.
>      > ---

[...]

>      >
>      >  char Usage[] = "\
>      >  Usage: ttcp -t [-options] host [ < in ]\n\
>      > @@ -173,16 +220,34 @@ void millisleep(long msec)
>      >    nanosleep( &req, NULL );
>      >  #endif
>      >  }
>      > +
>     Avoid making own changes outside of the __rtems__ guards if you're
>     trying to preserve compatibility with the upstream. Please read
>     contributing.md.
> 
> 
> This one is a weird case. To run the ttcp benchmark, you must have two
> systems running it. One is the Tx and the other is the Rx. This usually
> means you are running TTCP on your RTEMS target and on your development
> system. Some of these are needed to be clean on the native build. Other
> parts are specific to RTEMS.
> 
> As you can tell from the date on the code it is quite old and it is 
> questionable
> if there is a maintained upstream.for this implementation. In answering 
> this,
> I found https://en.wikipedia.org/wiki/Ttcp 
> <https://en.wikipedia.org/wiki/Ttcp> which points to nuttcp.net 
> <http://nuttcp.net> and that
> appears to be maintained since there was a release last year. But that's 
> GPLv2
> so we won't be using that.

Benchmarking is a quite specific use case and normally only added during 
testing and not in a final application. I think if nuttcp is an 
interesting tool, GPLv2 shouldn't be a big problem in this case. The 
only problem: It would have to be in a separate repository and not in 
libbsd. Alternatively the maintainers might accept patches that allow 
using nuttcp as a library so that we don't have to add a clone of the 
sources in RTEMS at all.

> 
> We need some changes to make it clean natively and some to make it work
> on RTEMS. And I don't think there is really an active upstream for this. 
> This
> was a new port based on newer ways of doing things in RTEMS. What
> do you think is best?
> 

Normally I would start with the version that is provided by the FreeBSD 
ports collection (which would be from 06.04.2021 at 
https://www.freshports.org/benchmarks/ttcp/), apply the FreeBSD patches 
to it and then use the normal __rtems__ markers. With that we can use 
the FreeBSD patches for that if there are updates necessary.

Like I said: That would be my method. Don't feel forced to use that.

> It occurred to me as I typed this that perhaps the native version should
> be built as part of rtems-tools instead of assuming the end user would
> compile this source by hand from libbsd. But then we would be duplicating
> the file.
> 

We now have two network stak repos and maybe someone adds lwip to a 
separate repository somewhen. Wouldn't it be better in that case to have 
a fork of ttcp in a separate repository anyway so that it can be used 
with all stacks and (maybe) also build as a host tool with rtems-tools?

I didn't have a look at ttcp (or nuttcp) and I'm not sure whether it 
depends heavily on the host operating system or not. If it is heavily 
adapted to the FreeBSD stack, compiling it as a stack-independent 
library won't work. Please just say so if that is the case.

Please note that I don't want to insist on that (or any of the other 
points above). It just might would be a possibility to avoid duplicating 
code to every network stack repo and the host.

Best regards

Christian

> Not a good solution all around. I suspect we really cloned and owned.
> 
> --joel
> 
> 
[...]