Re: Networking API example code


Paul Sokolovsky
 

Hello Patrik,

As we were requested at the TSC meeting to keep the discussion public
at the devel mailing list, please let me re-route this conversation
there.

I also apologize for delayed response - there were public holidays
here. Please see responses below.

On Fri, 27 Apr 2018 15:10:18 +0300
Patrik Flykt <patrik.flykt@linux.intel.com> wrote:

Here is a fairly simple piece of C code that we can use to demonstrate
different networking APIs in Zephyr. It's simple, as the request was
to present the APIs in the Networking Forum next week. Of course a
more realistic example would be much more elegant, but then time
would be spent on deducing the internal flow of the program, which
will not create any more clarity on the matter.
As I mentioned in my previous mail (dated Apr 26,
https://lists.zephyrproject.org/g/devel/topic/examples_for_zstream/18100280),
Zephyr tree includes 5 ready socket examples which demonstrate socket
API from various angles and are known to work. I proposed to use one of
them to demonstrate TLS API approaches.

Your going forward with an adhoc example may leave an impression that
your API can't work with existing examples, and require an artificial
one - which is definitely not true.

But your going with a single-source-file example also hides what the
existing Zephyr socket samples are. They are fully self-contained
(albeit small and "toy") applications with build files included, and
these build files demonstrate thess apps working on both Zephyr and a
reference POSIX system (tested with Linux).

Samples for my Zstream API preserve this continuity. And that's where
your API would have problems. And I hope it's not just me who's keen to
see how you'd resolve that.

So, I hope you had time over the last week also convert one of the
samples at
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/sockets
to your API and test it with both Zephyr and a POSIX system.

Oh, and btw, your sample code had a mistake, so couldn't work as is, I
had to fix it.


I was thinking that the code that is changed/added could be indicated
for example by color, so that the modifications needed by each API and
proposal would be easy to spot. As the code is quite short, it might
even be possible to squeeze the samples on two slide pages each. With
that we then can present the original example socket code below, the
Net App version, Zstream and socket option version in a reasonably
short time in an understandable way.
Fairly speaking, Zstream was at that stage - discussing individual
calls in a presentation-like manner circa beginning of February (and
that was done on github). The way I understood TSC's request is to
prepare 2 more or less real-world samples to compare 2 APIs. I didn't
try to squeeze mine into the presentation slides. I also let Github diff
viewer do the coloring:

https://github.com/pfalcon/zephyr/pull/2/commits/735ba51e56a191e45e9afb7f1a5e221976451e67

This is your sample, as-is from the mail.

https://github.com/pfalcon/zephyr/pull/2/commits/bc1dbb75c5f76739681f9d44eb755f50bb45bc2b

This adds missing connect() call, and build files for Zephyr and POSIX.
This represents a working, testable sample.

https://github.com/pfalcon/zephyr/pull/2/commits/8d2cf8da1fddf946ea8912a327e76d28e05fcaba

This shows the changes required to convert socket-based sample to
Zstream-based sample, still preserving buildability and functioning on
both Zephyr and POSIX.

(Links are valid until git rebase.)


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Join devel@lists.zephyrproject.org to automatically receive all group messages.