[lwip-users] Re: [lwip] RFC - new sys_arch for lwIP 0.5

[Peter Graf]

Hi Adam,

here's a little feedback:

>The general idea is that porting lwIP to new architectures
>requires only small changes to a few header files [...]

Why not name them exactly? Just sys_arch.h and lwipopts.h except for device
drivers?

>- u16_t sys_arch_sem_wait(sys_sem_t sem, u16_t timeout)
>
>  [...]
>
>  If the timeout argument is non-zero, the return value is the amount
>  of time spent waiting for the semaphore to be signaled. If the
>  semaphore wasn't signaled within the specified time, the return
>  value is zero. If the thread didn't have to wait for the semaphore
>  (i.e., it was already signaled), the return value should be 1.

If already signaled: Is it enough to return a small value, or must it be
*exactly* 1?

Background: On some OS, including eCos, the already implemented timed wait
for semaphore will not tell wether it was already signaled. The time spent
waiting can be measured, but may not exactly tell if there was *no* waiting
or a *little* waiting.

>- u16_t sys_arch_mbox_fetch(sys_mbox_t mbox, void **msg, u16_t timeout)
>
>  Blocks the thread until a message arrives in the mailbox, but does
>  not block the thread longer than "timeout" milliseconds (similar to
>  the sys_arch_sem_wait() function).

Same return values as sys_arch_sem_wait() expected?

Thanks a lot for implementing and documenting the new sys_arch interface!

All the best

Peter



[This message was sent through the lwip discussion list.]