RE: [lwip-users] sys_timeout

[Curt McDowell]

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On 
> Behalf Of Peter Graf
> Sent: Monday, March 06, 2006 2:27 PM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] sys_timeout
> 
> Curt McDowell wrote:
> 
> > The way sys_arch is implemented, timeouts can only fire 
> when the main 
> > process is sleeping on a semaphore or mailbox using either
> > sys_sem_wait() or sys_mbox_fetch() in src/core/sys.c.
> > 
> > I think it's an architectural deficiency that any of 
> sys_arch is implemented in the lwip core.
> 
> I found it a benefit.

Peter,

To be clear: I'm not denigrating the idea of sys_arch, which is a typical 
example of a system abstraction layer and is critical for
portability.  All of the API definitions it provides are fine.

However, sys_arch is not doing its job.  It needs to be a clean layer between 
lwip and the underlying operating system, but instead
it's inextricably tangled into lwip.  For portability, it should be possible to 
completely replace the implementation of that layer.

No part of sys_arch belongs in lwip core.  All of the sys_arch implementations 
should reside fully in the contrib platform ports.
To wit, half of sys_arch is implemented in one particular way (core/sys.c), 
severely limiting what can be done to port the other
half.

What about those portions of code that are thought to be common across *all* 
platforms?  First, there are none, as the troubling
examples below will illustrate.  Second, as you noted, in a proper multitasking 
O/S it is an easy matter to map each call.  Third,
even if there is common code between some of the ports, that's no reason to put 
it in lwip core instead of contrib.

My operating system has its own perfectly good timeout function.  However, I'm 
unable to use it because the core of lwip depends
(incorrectly) on specific internal functionality of sys_timeout.  If I were 
able to provide my own sys_timeout, I would be fine.  I
should be able to have a simple file for my OS that defines 1-for-1 versions of 
all the sys_arch APIs.

The mere existence of the pseudo-API calls sys_timeouts(), sys_arch_sem_wait() 
and sys_arch_mbox_fetch() provide further evidence
that something is broken.  These calls are unclean and should not be necessary.

> > Worse, any application that wants to use lwip is forced to 
> be based on lwip's sys_arch primitives.
> 
> If lwIP is intialized and the main+tcp+interface threads are 
> active (this can be set up outside the application), the 
> application just has to link itself into lwIP's thread list 
> once. Afterwards it is free to call the lwIP networking 
> API(s) or not, but it's not required to use the sys_arch primitives.

The latter is not a true statement.  Say your O/S has its own semaphore wait, 
which nearly all do.  Your application can never call
it instead of the sys_arch version, or sys_timeouts will cease.  This forces 
your whole application to be rewritten based on
sys_arch.  That is unreasonable, and in my (large) application, not possible.  
If sys_arch is properly separated out, this would no
longer be a problem.

Regards,
Curt McDowell
Broadcom Corp.