lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] Re: [bug #26397] SLIP polling support


From: Simon Kallweit
Subject: [lwip-devel] Re: [bug #26397] SLIP polling support
Date: Fri, 21 Aug 2009 08:28:54 +0200
User-agent: Thunderbird 2.0.0.22 (X11/20090608)

Kieran Mansley wrote:
Follow-up Comment #2, bug #26397 (project lwip):

I don't think there's any particular reason why this has failed to be
applied, just that it hasn't been a high priority.

Ok, then let's look forward to get it included now. Similar work should be done on the PPP netif, so it can also be used in a polled/single-threaded environment.

Looking at the patch, it seems to change a lot of code that isn't necessary
to add the slipif_poll() function.

Well, actually there is not that much code. I think we should try to share code for both the polled and the threaded versions, so that's what most changes are for.

The struct slipif_priv is used for private data of the SLIP interface, as we cannot have them as local variables anymore. The changes in slipif_output() are due to the introduced slipif_priv structure. Nothing else changed. slipif_input() had to be changed more significantly. The old version would block until a new packet was received. The new version will return NULL if all data has been read from the serial and no complete packet was received, but it will keep track of partially received packets, so the next call to slipif_input() can finish the process.

If you could give more detail about the
need for the other changes (a good example is the change from sio_read to
sio_recv) that would help.  Some of the changes are obviously improvements and
bug fixes, but a lot aren't obvious at first glance to someone not familiar
with the sio code.

Well, the change from sio_recv() to sio_read() is quite simple, sio_recv() directly returns the received character from the serial line and is therefore not useable in a polled mode. sio_read() on the other hand can return without actually receiving data.

The sio API in general is a bit lacking when it comes to blocking/non-blocking operation. I was wondering if it should be extended to support some sort of configuration. We should also add some documentation I think.

Instead of using sio_read() we could also introduce some method sio_peek() to check if there are characters waiting to be received. But this would change the API.

Also, in regard to PPP, we should add an API to get/set modem control lines.

There also seem to be a lot of whitespace changes that make the patch a bit
harder to read: the whole copyright message for example shouldn't be in the
patch.

I can remove this. But it's just a bit of cleaning up.

Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]