lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] Mods to the LWIP BSD Socket's emulation layer..


From: Craig Graham
Subject: [lwip-devel] Mods to the LWIP BSD Socket's emulation layer..
Date: Mon, 19 Jul 2004 12:12:27 +0100
User-agent: KMail/1.6

I just started looking at LWIP a couple of weeks ago, and was wondering how 
I'd go about submitting mods to the codebase?

Bit of background - the firm I work for supports Open Source software to the 
extent that they're happy for mods/improvements made by us to be released 
back to the community. We used uCIP in one of our products previously, and as 
part of that development I added the UDP and DHCP protocol support in uCIP.

Anyway, uCIP is old news and I've suggested LWIP might be suitable 
replacement, as a test of that I've just ported LWIP to our in-house RTOS.

During that I noticed a couple of things that needed attention in the BSD 
socket's API emulation. The first is a simple bugfix to the handling of
FIONREAD in sockets.c - if a previous read didn't use up the contents of an 
entire netbuf, the lastdata field will still hold data and this amount of 
data wasn't being included in the amount returned by FIONREAD.

1322c1325,1326
<
---
>   u16_t l;
>
1335c1339,1344
<     *((u16_t*)argp) = sock->conn->recv_avail;
---
>     l=sock->conn->recv_avail;
>     if(sock->lastdata)
>     {
>       l+=netbuf_len(sock->lastdata)-sock->lastoffset;
>     }
>     *((u16_t*)argp) = l;

The second is a more of a feature enhancement, and is a bit in-depth to post 
on a mailing list (adds non-blocking support to lwip_connect(), controlled by 
the FIONBLOCK flag). What's the formal procedure for submitting stuff like 
this?

Laters,
Craig.




reply via email to

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