[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] sys_timeout
From: |
Peter Graf |
Subject: |
Re: [lwip-users] sys_timeout |
Date: |
Tue, 07 Mar 2006 09:53:23 +0100 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
Hi Curt,
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.
But portability to what? If an OS can not provide the requirements lwIP
has now, I can not see how it'll meet what is required for a
multitasking networking implementation anyway.
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.
If your multitasking O/S has just semaphores with timeouts and shared
memory, you _are_ fine. In my case, I didn't even have semaphores in the
OS, just timeouts, and I implemented the semaphores with timeouts myself.
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.
They are not broken (at least not in the somewhat older version I'm
using). The internal mechanism is just a bit hard to understand and not
elegant at some points. But someone who just wants to port lwIP doesn't
need to care.
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.
I guess this is a misunderstanding which comes up here every now and then.
If your thread calls the semaphore wait of the OS directly, it is
already implicitely sure that _this_ thread doesn't have timeouts in
lwIPs list. (It could only have timeouts in the list if a blocking call
into lwIP's API was ongoing in it's own context). The timeouts of the
other threads are not affected if this thread uses the OS's mechanisms
in parallel (unless the OS is broken).
This forces your whole application to be rewritten based on
sys_arch.
No :-) I have several applications running fine, none was rewritten
except for the networking calls and a startup function which makes sure
that lwIP is up and I link my thread(s) in it's list.
That is unreasonable, and in my (large) application, not possible. If sys_arch
is properly separated out, this would no
longer be a problem.
If it was separated out, the risk of misunderstandings and erratic
architecure layers rises. This could cause maintainance problems.
All thge best
Peter
- [lwip-users] sys_timeout, Christiaan Simons, 2006/03/04
- RE: [lwip-users] sys_timeout, Curt McDowell, 2006/03/06
- Re: [lwip-users] sys_timeout, Peter Graf, 2006/03/06
- RE: [lwip-users] sys_timeout, Curt McDowell, 2006/03/06
- Re: [lwip-users] sys_timeout,
Peter Graf <=
- RE: [lwip-users] sys_timeout, Curt McDowell, 2006/03/07
- RE: [lwip-users] sys_timeout, Christiaan Simons, 2006/03/08
- Re: [lwip-users] sys_timeout, Peter Graf, 2006/03/08
- RE: [lwip-users] sys_timeout, Curt McDowell, 2006/03/08
- Re: [lwip-users] sys_timeout, Peter Graf, 2006/03/08
- Re[2]: [lwip-users] sys_timeout, Paulo Figueiredo, 2006/03/08
- Re: [lwip-users] sys_timeout, Peter Graf, 2006/03/08
- RE: [lwip-users] sys_timeout, Curt McDowell, 2006/03/08
- [lwip-users] Bind port problem, Etienne Lanoy, 2006/03/09
- Re: [lwip-users] Bind port problem, Atte Kojo, 2006/03/10