Date: Fri, 22 May 2015 16:14:27 -0300
From: Daniel Gutson <address@hidden>
To: lwip-devel <address@hidden>
Subject: Re: [lwip-devel] Adding a static route table in LwIP
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
El 22/5/2015 16:07, "Russ Dill" <address@hidden> escribi?:
On Fri, May 22, 2015 at 9:52 AM, Daniel Gutson
<address@hidden> wrote:
On Thu, May 21, 2015 at 12:59 PM, Ivan Delamer
<address@hidden>
wrote:
Hi Pradip,
I think a static IPv6 route table is a nice feature to have. I
think
some
people have implemented something similar for IPv4. Also someone
has
implemented a NAT.
Hi all.
Sorry if my question/suggestion is completely out of place. Please
note that I'm not a telecommunications expert,
but a user (of real time and embedded systems which use LwIP).
Would adding this as a plug-in be a good idea?
Or more specifically: would an extension mechanism where features
like
this one could be added
aside of the core library? Of course I don't mean dynamic loading,
but
just to provide a set of hooks
placed in the right places so extensions could register callbacks.
Could that make sense? The first step would be to add the
appropriate
hooks (then refactor this feature
and possible other features such as NAT as well, so they can be
written as opt-in extensions?).
The main purpose would be neat maintainability.
Please let me know. If this happens to make sense, we could see how
to
collaborate.
Both solutions are possible, but keep in mind that lwIP is "a
light-weight implementation of the TCP/IP protocol suite", and "The
focus of the lwIP TCP/IP implementation is to reduce the RAM usage".
So any patch to lwIP has to take into account bloat. Adding a feature
that can be compiled in or out does not effect the size of lwIP for
users that do not enable that feature. Adding hooks that can call
into
external or compiled in modules increases the code size even for
users
that don't enable that extra module.
Agree and I'm fully aware of that fact since I'm specially interested
about
it: we put LWIP on RTEMS on a 32k RAM board :)
The hooks could be preprocessor-conditionally enabled or disabled by
macros
associated to functionality families, such as
#ifdef ENABLE_XXXX_HOOKS
call_xxx_callbacks();
#endif
_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.nongnu.org/archive/html/lwip-devel/attachments/20150522/f3c4d14e/attachment.html>
------------------------------
_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel
End of lwip-devel Digest, Vol 131, Issue 17
*******************************************