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

[Adam Dunkels]

Hi Peter!

On Wednesday 14 November 2001 10:08, you wrote:
> >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?

The full list also includes cc.h and cpu.h. The reason for not naming them 
here is that I am writing another small note on porting which focuses more on 
the practical issues such as fixing #include paths, which files to edit, etc. 
But perhaps I should include it here as well?

> >- 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.

It is enough to return a small value. The problem is that if the semaphore is 
signalled, the time spent waiting for it will be zero and if the return value 
0 is used to indicate that a timeout occured. I'll reword to:

  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), care must be taken to ensure that
  the function does not return a zero value since this is used to
  indicate that a timeout occured. A suitable way to implement this is
  to check if the time spent waiting is zero and if so, the value 1 is
  returned.

> >- 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?

Yes. I'll add the following text:

  The return values are the same as for the sys_arch_sem_wait()
  function and the function must not return zero even if a message was
  present in the mailbox and the time spent waiting was zero
  milliseconds. 

  Note that a function with a similar name, sys_mbox_fetch(), is
  implemented by lwIP. 

Also, I completely forgot about one new function needed in the sys_arch 
module, sys_arch_timeouts():

- struct sys_timeouts *sys_arch_timeouts(void)

  Returns a pointer to the per-thread sys_timeouts structure. In lwIP,
  each thread has a list of timeouts which is repressented as a linked
  list of sys_timeout structures. The sys_timeouts structure holds a
  pointer to a linked list of timeouts. This function is called by
  the lwIP timeout scheduler and must not return a NULL value. 

  In a single threadd sys_arch implementation, this function will
  simply return a pointer to a global sys_timeouts variable stored in
  the sys_arch module.
  
Thanks Peter for your feedback!

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]