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

[Daniel Gutson]

El 25/5/2015 15:26, "Ivan Delamer" <address@hidden> escribió:
>
> Hi,
>
> A hook is the way to go. Check master branch, you can define LWIP_HOOK_IP6_ROUTE for this purpose.

A hook should not know what it will be used for, but be a place where plugins can register their callbacks.

>
> This will allow you to choose the proper netif based on your own static routing. The stack will then select the correct source address. In your netif->output_ip6 function you would then resolve your router MAC address, either through ND6 or through the static table (or a mixed approach, however you implement it).
>
> Cheers
> Ivan
>
>
>> 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
>> *******************************************
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel