[Top][All Lists]

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

[lwip-devel] [patch #5914] Move sockopt processing into tcpip_thread

From: Jonathan Larmour
Subject: [lwip-devel] [patch #5914] Move sockopt processing into tcpip_thread
Date: Sat, 05 May 2007 00:38:33 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051202 Fedora/1.5-0.fc4 Firefox/1.5

Follow-up Comment #18, patch #5914 (project lwip):

Frédéric Bernon wrote:
> Socket "problems" are mainly "lot" of parameters checking (not useful if
> are sure about your parameters), and impossible to get a zero-copy for
> receive (adding a memcpy)... What else?

- With standard BSD API, impossible to get zero-copy for transmit either. 

- Impossible to indicate that something is immutable (e.g. ROM) for TCP.

- All API funneled through same functions, so no possibility of linker
removing unused ones on basis of which API function is called. setsockopt is
the best but not only example. So a function like netconn_option() would be
bad. netconn_option_ip, netconn_option_tcp, netconn_option_udp, etc. would be

- select(). Look how much code is needed to handle the imposed API
requirements. Enough said.

- struct lwip_socket contents and file descriptor arrays.

If you correct all these, you have something very unlike the BSD API. With a
non-standard BSD API.... well why not call the netconn API the non-standard
API :-). I'm only half-joking - if there was an official way within the
sockets implementation to get the underlying netconn, we would be most of the
way there.

> Your solution, to my point of view, is just a new and redundant
> "tcpip_apimsg" (synchrone call to tcpip_thread). Even, note that in
> CVS, tcpip_callback is only used by PPP, and should have to be disable if
> PPP interfaces is used...

I could argue the converse - the whole api_lib/api_msg structure could be
turned around and replaced with tcpip_callback()s. Then underlying
functionality is only included if used. Right now, because of the dispatch
table it's always all included.

Anyway that thought is a general one, and I'm not necessarily trying to say
we should start adopting the practice right now.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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