[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-net
Subject:    Re: route_protosw.pr_input
From:       Maxime Villard <max () m00nbsd ! net>
Date:       2018-09-07 9:20:05
Message-ID: a6f813a7-60c4-17c3-62b3-bb3ddea9b9df () m00nbsd ! net
[Download RAW message or body]

Le 07/09/2018 à 11:02, Ryota Ozaki a écrit :
> On Fri, Sep 7, 2018 at 4:01 PM Maxime Villard <max@m00nbsd.net> wrote:
>> Le 06/09/2018 à 10:45, Ryota Ozaki a écrit :
>>> On Wed, Sep 5, 2018 at 4:37 PM Maxime Villard <max@m00nbsd.net> wrote:
>>>> In net/rtsock.c, I don't understand where we use the 'pr_input' field of
>>>> COMPATNAME(route_protosw)[]. To me it can't be used: .pr_input takes a
>>>> variadic function, but if you grep through the tree, you can see that
>>>> the variadic .pr_input functions we call always take three arguments, as
>>>> opposed to raw_input() which takes five.
>>>>
>>>> Therefore raw_input() is never called via .pr_input, and we can set the
>>>> field to NULL. Then we can switch all the .pr_input functions to be static
>>>> and not variadic.
>>>>
>>>> This will clear a lot of confusion, and will allow us to find problems
>>>> related to types -- like this one.
>>>>
>>>> Comments?
>>>
>>> No objection.
>>>
>>> And a next step would be to change the signature of protosw#pr_input
>>> to that of ip6protosw#pr_input and then we can merge protosw and
>>> ip6protosw into one.
>>
>> Is it a really good idea? To me it would be better if the IPv4 pr_input
>> stayed as
>>
>>          void x_input(struct mbuf *m, int off, int proto)
>>
>> I don't see a lot of point in wanting to mimic IPv6; IPv6 has constraints
>> that don't apply to IPv4. Eg the second arg is a pointer, because of the
>> format of the IPv6 options -- but that doesn't apply to IPv4.
>
> I just prefer having just one structure to having two similar structures,
> which reduces some codes.
>
> (Well, and FreeBSD / OpenBSD / Dragonfly BSD did the change.)

In this particular case I don't think it's a really good move. The IPv6
code is already a bit difficult to track because of *offp, so if we start
doing the same for IPv4 there will be blood.

We can still make the change later if it turns out to be really better.
[prev in list] [next in list] [prev in thread] [next in thread]