Re: [lwip-devel] Adding a static route table in LwIP

[Daniel Gutson]

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