[Top][All Lists]
[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.
- [lwip-devel] Mods to the LWIP BSD Socket's emulation layer..,
Craig Graham <=