Hello Jukka,

On Mon, 19 Jun 2017 14:39:33 +0300
Jukka Rissanen <jukka.rissanen@...> wrote:

Hi all,

There has been discussion and complaints that the current net_context
API that applications can use is too low level and requires lot of
effort from application developer to create a bug free application.
Many networking operations that various applications do, are very
similar and can be provided by a library. In order to address these
issues I created a higher level API that applications can use.

Thanks for posting this RFC. It touches some issue I also wanted to
post RFC about: with (1st stage of) BSD Sockets work nearing completion
https://github.com/zephyrproject-rtos/zephyr/pull/498 , it would be
nice if all think about "responsibilities division" between 2 APIs.
The initial idea would be:

1. Native Zephyr API has the smallest code size and minimal overhead.
2. Sockets API is familiar to large audience.

Perhaps, thinking about it in these terms would help to design and
develop APIs further. For example, Sockets API is by definition
takes more code size than native API as it's implemented on top of it.
But if native API keeps growing, that undermines one of it benefits.
Likewise, native API is more memory efficient as it minimizes copies.
But it also cumbersome to use. But if we try to work that around by
another API layer, still adhoc, then perhaps just using Sockets API is
a viable alternative for such usecases?

Note that this doesn't have to be a deciding factor for your current
proposal, but it would be nice if we started to look at these matters
from this perspective - that instead of scope-creeping existing
API/featureset, accept that we have 2 APIs with orthogonal features
with their weaknesses and strengths, and maintain them as such.

This API can be found
in https://github.com/zephyrproject-rtos/zephyr/p ull/540 and you can
either give comments there, or here if you wish.

The API consists of two parts:

1. Application initialization support.
* The net_app_init() makes sure that we have IP address, routes etc.

Giving an example of the application of the ideas above, with my "BSD
Sockets" hat on, for writing "fully portable" BSD Sockets/Zephyr apps,
I'd think how to make this configuration completely declarative, using
CONFIG_* options, to not require patching code in the Zephyr case with
this net_app_init() call.

Questions: do you think this would make sense at all, and would be
acceptable? Then, would we need this explicit net_app_init() call in
addition to declarative config? If so, how to make declarative and
imperative config to blend well together, e.g. declarative to be built
on top of net_app_init(), instead of e.g. having 2 separate code
modules?

[]

This net_app API will replace the internal net_sample_app API that was
used by some of the network sample applications found under
samples/net directory.

Ok, so if this new API is further evolution of net_sample_app, I'm
definitely +1 on it. But would like to know whether the API evolution
leads us at all, and how to make this API to cover BSD Sockets usecases,
like declarative config.


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