Kieran Mansley wrote:
On Tue, 2007-02-27 at 11:43 +0200, Atte Kojo wrote:
As far as I understand sys_arch_sem_wait is guaranteed to exist, so why
implement redundant functionality for just one function (lwip_select).
Erk, can't remember - too long ago! If this is causing a problem I
might be able to look into it, but my best guess is that it's a code
cleanness thing. i.e. perhaps it wasn't intended to be using the
sys_arch_* code up in the sockets layer.
I don't think it's causing any problems, it just seems rather
cumbersome. What comes to using sys_arch_* code in upper layers, all
semaphore functions except sys_sem_wait are implemented in sys_arch.c
anyway (same thing for *mbox* functions); the naming scheme is not the
most logical here.
As there has been quite a lot of confusion about using timers in the
past, I'd like to propose the following: replace all the
sys_mbox_fetch() and sys_sem_wait() functions in the
socket/netconn-layer with their sys_arch-counterparts and implement the
timer functionality only in tcpip_thread. Or better yet, rename
sys_arch_sem_wait() -> sys_sem_wait() and sys_arch_mbox_fetch() ->
sys_arch_mbox_fetch() and implement a special timer mechanism for
tcpip_thread.
Unfortunately I cannot really help with the coding since the code I use
differs in parts quite a lot from the original code (expert advice:
never EVER try to implement a TCP/IP stack for a DSP that doesn't do
byte addressing).
PS. Since I'm wishing stuff here, I'd also like to see netconn API
merged into the socket API (netbuf stuff could probably be thrown away
in the same haul). :-)
- Atte
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
