On 15/06/2021 20:03, Joel Sherrill wrote:
On Tue, Jun 15, 2021 at 10:25 AM Gedare Bloom <ged...@rtems.org
<mailto:ged...@rtems.org>> wrote:
On Fri, Jun 11, 2021 at 11:19 AM Stephen Clark
<stephen.cl...@oarcorp.com <mailto:stephen.cl...@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
[...]
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
