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

[Jonathan Larmour]

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

Frédéric Bernon wrote:
> 
> Socket "problems" are mainly "lot" of parameters checking (not useful if
you
> 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
better.

- 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
current
> CVS, tcpip_callback is only used by PPP, and should have to be disable if
no
> 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:

  <http://savannah.nongnu.org/patch/?5914>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/