Kaspar Schleiser

> The actual implementation could still choose to make the "start conversion" function a non-op. that makes total sense. code would still work, just maybe a bit slower.

> The reason why we did not include `ipv{4,6}_addr_t` was to keep the sock API RIOT-independent (which was something @kaspar030 fought for hard). IMO, keeping it that way also keeps...

So, ``` typedef struct { uint8_t bytes[IPV6_ADDR_LEN]; } ipv6_addr_t; ``` ? - not using plain array type so it can be returned from functions - not using any union so...

this is how it looks in linux: ``` 33 struct in6_addr { 34 › union { 35 › › __u8› › u6_addr8[16]; 36 #if __UAPI_DEF_IN6_ADDR_ALT 37 › › __be16› ›...

The problem here is that the 6lowpan RFC is very clear on what is supposed to happen if there's no neighbor cache entry: forward the packet to _any_ router available....

won't be fixed for this release -> postponed

> I'm not sure if anything on the system level relies on the event thread though, so this would then only block user applications which is probably fine. Hm, that's...

please don't put this in `core/`, if possible...

> we could use bit-banding That does uglify the code a lot...

> > Real-time side effects are almost non existant ... > > If they are present they may add up, so please document them unless there is good reason not...