[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160616.141805.201276959937562482.davem@davemloft.net>
Date: Thu, 16 Jun 2016 14:18:05 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: dsa@...ulusnetworks.com
Cc: hannes@...essinduktion.org, netdev@...r.kernel.org, ja@....bg
Subject: Re: [PATCH RFC 1/3] ipv4: make flow functions more grepable by
removing flowi4_init_output
From: David Ahern <dsa@...ulusnetworks.com>
Date: Wed, 15 Jun 2016 14:29:28 -0600
> On 6/15/16 1:48 PM, David Miller wrote:
>> But if people don't use the helpers, and initialize flow structures
>> on their own, yeah that defeats the whole mechanism and things will
>> seem harder and "unhelpful".
>
> That's my point -- the flow struct does not have a consistent
> initializer. There have been a number of bug patches over the past
> year like 4cfc86f3dae6 to handle uninitialized elements. My suggestion
> here is the same as 4cfc86f3dae6 which is to initialize the flow when
> it is declared.
>
> Consider the recent change from Hannes for 38b7097b55b6. fl6 can be
> initialized when it is declared with a bit of straightforward
> refactoring -- icmp6_send has an easy split into 2.
>
> Seems like that is a more robust long term solution considering the
> various init use cases.
The danger with initializers is it puts the burdon all over the tree.
So now there are many places that need to be audited when a new
element is added.
So from my perspective, the bug is that the code in question did
things by hand rather than using the helper function.
If everyone used the flow initializer helpers, the compiler would
tell us every place that needs to be fixed up.
By doing initializers inline, this process of discovery is more
difficult and error prone.
Powered by blists - more mailing lists