[lwip-devel] sys_* functions in NO_SYS=1

[AjK]

I think this is more of a lwip-devel question that a lwip-user question, 
apologies if not.

I was wondering why in sys.h beginning line 41 the code base goes to such harse 
lengths to make sure a NO_SYS=1 system is not to be able to define functions 
such as sys_box_new() etal and the typedefs such as typedef u8_t sys_mbox_t;

I'll explain. I have just finished a NO_SYS=1 device driver and a netif. Then, 
I 
decided it would be nice to re-factor the design to be "RTOS friendly".

Now, in my original design the driver dispatches packets to the netif which 
queues them for processing. For this I created my own simple queues and it all 
worked fine.

But when I came to do the RTOS friendly version, I hit on the idea that in the 
driver/netif interface, specifically where I used queues, I could harmonize by 
using the sys_arch.h abstraction layer. In RTOS builds my driver/netif would 
use 
the queue mechanism provided by the RTOS. However, in NO_SYS=1 I would simply 
create my own fundamental queue primitive that complied with the same interface 
(sys_mbox_new()... etc).

That way my netif code could be the same for any build I did. I only then had 
to 
worry about ensuring sys_arch.h/.c was fit for the build taking place 
(abstraction in one place).

However, sys.h bars me from using the typedefs and function prototypes by 
defining a "null set". I had a quick look through the code to see where a null 
version would be used and it seems to me they are all conditional and don't get 
compiled in a NO_SYS=1 situation. So why are these not available in a NO_SYS=1 
situation?

The only solution I can see now is to have two versions of the netif code, one 
for NO_SYS=1 and one for NO_SYS=0 just because these prototypes are not 
available. So having to maintain two sections of code when just maintaining the 
sys_arch.h/.c would have been much simpler.

--Andy