[ONME-2844] Avoid option level collisions

[hasnainvirk]

To allow a network stack to support both NSAPI and its own options, try to make
sure the NSAPI levels don't collide with level numbers likely to be used by
network stacks.

Distinguish between socket and stack options, and tighten up documentation. Add
IP MRU stack options as an example (implementation not immediately planned for
any stack, but could be useful).

[hasnainvirk]

@sg- @c1728p9 @bridadan @geky Please review

[0xc0170]

@hasnainvirk Can you please look at continuous-integration/jenkins/pr-head why it fails?

[geky]

The original motivation was to allow users to dynamically configure network stacks the same way they can configure network sockets. Unlike most socket APIs we provide an abstract nework stack, so there needs to be a different route for stack specific options.

Linux has the ioctl function that can, say, set the MTU size of a network stack. To replace it, the nsapi provides a setstackopt member function that mirrors setsockopt with its own level of options.

Most stack configuration is currently static at compile time to take advantage of memory savings, so the setstackopt has seen little use. It may not be worth keeping around, but also doesn't seem to be bothering anyone.

---

Tangentially, this pr seems like a good idea. Maybe it'd be better to use an offset of 3000 to match the error codes?

[kjbracey]

Hmm, I was totally unaware of setstackopt - never noticed it, or had forgotten. Seems like a reasonable concept. Nanostack has a number of run-time config options.

So if NSAPI_SOCKET and NSAPI_STACK aren't two values for setsockopt (as I assumed) they aren't necessarily part of the same number space - they could possibly both be the same value.

I note the comments next to the option enums all say "stack options" rather than "socket options" - needs a little fixing and clarifying I think.

[hasnainvirk]

@0xc0170 It isn't failing anymore.

[bridadan]

Kicking off the bot and requesting reviews!

/morph test-nightly

[kjbracey]

Was my original suggestion, so I'm fine with the concept, but I think we do need to fix the comments up a bit.

NSAPI_STACK isn't doing anything at the moment as it's a "standardised level" for getstackopt without any actual options defined, which caused my confusion.

Anyone got a suggestion of some standardised stack option they might want so we can put it in as a placeholder in a new stack options enum? "IP reassembly size" might be topical. (Nanostack's arm_nwk_ipv6_frag_mru(), but that's actually write-only at the minute).

[geky]

@hasnainvirk, sorry for adding work to your pr, but would it be too difficult to change the "stack options" to "socket options" in the neighboring lines?

We can probably hold off on adding stack options until they are added to an implementation. Maybe the mru setting should be added to the NanostackEthernetInterface? The flag could be added to the option enum in the same pr.

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1292

All builds and test passed!

[hasnainvirk]

@geky can you be please kind enough to review this PR again ?

[geky]

This looks reasonable to me 👍

[0xc0170]

/morph test-nightly

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1306

All builds and test passed!

[0xc0170]

@kjbracey-arm @c1728p9 Happy with this patch?

[c1728p9]

Looks good to me 👍