On Fri, Sep 02, 2022 at 10:46:12PM +0200, Alexander Bluhm wrote:
> On Fri, Sep 02, 2022 at 06:01:20PM +0300, Vitaliy Makkoveev wrote:
> > We always call in6_setpeeraddr() and never call in_setpeeraddr() fro the
> > inet6 case.
>
> Should we do it the other way around?
>
> By pushing the inet6 case into the callee allows less switches in
> the callers. Instead of adding in6_sockaddr() and in6_peeraddr(),
> just call the generic in_...() version. The difference is only in
> in_setsockaddr() and in_setpeeraddr(). They can call the specific
> in6_...() implementation. This reduces code in upper layers.
>
> I did somethin like this a while ago and I think the code in the
> caller got cleaner. Of course this trick only works as long as
> in_...() and in6_...() have the same parameters.
>
> bluhm
This follows the pru_control direction, where we use different
in_control() and in6_control(), but they internals are absolutely the
same, except mrt{,6}_ioctl() and in{,6}_ioctl(), but they also have the
same parameters.
Personally I prefer the direction, where we have different handlers,
because inet and inet6 are different protocols, and I don't like to mix
them. Also I like the guenther@ proposition to split unix(4) sockets
dgram handlers, because this simplifies the code by removing not
reachable "default:" cases.
