netdev - Re: [PATCH net-next v3 2/3] sfc: support PTP over IPv6/UDP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 29 Aug 2022 09:03:44 +0200
From:   Íñigo Huguet <ihuguet@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     ecree.xilinx@...il.com, habetsm.xilinx@...il.com,
        davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next v3 2/3] sfc: support PTP over IPv6/UDP

On Sat, Aug 27, 2022 at 1:27 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Fri, 26 Aug 2022 08:39:44 +0200 Íñigo Huguet wrote:
> > > > +static inline int
> > > > +efx_filter_set_ipv6_local(struct efx_filter_spec *spec, u8 proto,
> > > > +                       const struct in6_addr *host, __be16 port)
> > >
> > > also - unclear why this is defined in the header
> >
> > This is just because it's the equivalent of other already existing
> > similar functions in that file. I think I should keep this one
> > untouched for cohesion.
>
> We usually defer refactoring for coding style issues until someone
> is otherwise touching the code, so surrounding code doing something
> against the guidance may be misleading.
>

Yes but I'm not sure what I should do in this case... all other
efx_filter_xxx functions are in filter.h, so putting this one in a
different place could make it difficult to understand how the files
are organized. Should I put the declaration in the header (without
`inline`) and the definition in a new filter.c file? Should I move all
other definitions to this new file?

Also, what's exactly the rule, apart from not using `inline`, to avoid
doing the same thing again: to avoid function definitions directly in
header files?

Thanks
-- 
Íñigo Huguet