[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241019122018.rvlqgf2ri6q4znlr@skbuf>
Date: Sat, 19 Oct 2024 15:20:18 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: Vladimir Oltean <olteanv@...il.com>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/8] lib: packing: add pack_fields() and
unpack_fields()
On Fri, Oct 18, 2024 at 02:50:52PM -0700, Jacob Keller wrote:
> Przemek, Vladimir,
>
> What are your thoughts on the next steps here. Do we need to go back to
> the drawing board for how to handle these static checks?
>
> Do we try to reduce the size somewhat, or try to come up with a
> completely different approach to handling this? Do we revert back to
> run-time checks? Investigate some alternative for static checking that
> doesn't have this limitation requiring thousands of lines of macro?
>
> I'd like to figure out what to do next.
Please see the attached patch for an idea on how to reduce the size
of <include/generated/packing-checks.h>, in a way that should be
satisfactory for both ice and sja1105, as well as future users.
View attachment "0001-lib-packing-conditionally-generate-packing-checks-ba.patch" of type "text/x-diff" (22717 bytes)
Powered by blists - more mailing lists