public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "Yury Norov" <ynorov@nvidia.com>,
	"Thomas Gleixner" <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	x86@kernel.org
Subject: Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
Date: Mon, 27 Apr 2026 10:42:52 +0100	[thread overview]
Message-ID: <20260427104252.5203a50e@pumpkin> (raw)
In-Reply-To: <dc1b12e74b3f487eb531bf7def806f10d9a18b5e.camel@sipsolutions.net>

On Mon, 27 Apr 2026 10:29:21 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> On Fri, 2026-04-24 at 12:35 -0400, Yury Norov wrote:
> > > I (personally) tend to prefer the "__MAKE_OP" versions (*_get_bits()
> > > etc.), in particular because WiFi and firmware interfaces deal a lot
> > > with fixed endian fields.  
> > 
> > I don't like that __MAKE_OP magic because whatever it generates is not
> > greppable. And because we disable strict type checks for kernel, but
> > this API claims to typecheck the parameters for the user. So, the
> > following compiles well:
> > 
> >         u64 val = 0;
> >         ret = le16_get_bits(val, GENMASK(15, 10));
> > 
> > I don't like autogeneration in general. We generate, for example,
> > be32_get_bits(), but never use it.  
> 
> That's a lot of "I don't like", but whatever.
> 
> 
> > We don't even know the level of the bloat.  
> 
> These are static inlines so there's no binary cost, and given that
> you're complaining about them being generated you can't really *also*
> complain about too much code...

There is a measurable compile-time cost for processing the definitions
of static inlines even when they aren't used.
While processing the definitions of #defines is cheap, processing the
expansions can be measurable. Particularly when expansions get nested
as often happens when GENMASK() is used as an argument to FIELD_xxx().

Even trivial #defines can affect compile times.
The 'size' check in READ_ONCE() (etc) costs about 1%.
(1% may not sound much, but find 10 of them and it becomes significant.)
I suspect a lot of that is adding the extra external function to hold
the error message.

	David

>  
> > > Any chance it'd be simple to generate u32_get_bits_signed() etc.? Could
> > > be especially useful for le32_get_bits_signed() for example, to have the
> > > endian conversion built-in unlike FIELD_GET_SIGNED().  
> > 
> > Maybe this:
> > 
> >         FIELD_GET_SIGNED(mask, le32_to_cpu(reg))  
> 
> Awful. "I don't like". But we rarely deal with bit-packed signed values
> anyway.
> 
> johannes
> 


  reply	other threads:[~2026-04-27  9:42 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-17 17:36 [PATCH 0/9] bitfield: add FIELD_GET_SIGNED() Yury Norov
2026-04-17 17:36 ` [PATCH 1/9] " Yury Norov
2026-04-17 18:12   ` Andy Shevchenko
2026-04-17 19:43   ` David Laight
2026-04-17 21:09     ` Yury Norov
2026-04-20  8:43   ` Johannes Berg
2026-04-24 14:50     ` David Laight
2026-04-24 16:35     ` Yury Norov
2026-04-24 21:37       ` David Laight
2026-04-27  8:29       ` Johannes Berg
2026-04-27  9:42         ` David Laight [this message]
2026-04-20 11:19   ` Peter Zijlstra
2026-04-20 17:54     ` Yury Norov
2026-04-21  9:27       ` David Laight
2026-04-17 17:36 ` [PATCH 2/9] x86/extable: switch to using FIELD_GET_SIGNED() Yury Norov
2026-04-20 11:24   ` Peter Zijlstra
2026-04-20 17:18     ` Yury Norov
2026-04-20 22:00       ` David Laight
2026-04-17 17:36 ` [PATCH 3/9] iio: intel_dc_ti_adc: " Yury Norov
2026-04-19 13:18   ` Jonathan Cameron
2026-04-17 17:36 ` [PATCH 4/9] iio: magnetometer: yas530: " Yury Norov
2026-04-19 13:20   ` Jonathan Cameron
2026-04-19 20:11   ` Linus Walleij
2026-04-17 17:36 ` [PATCH 5/9] iio: pressure: bmp280: " Yury Norov
2026-04-19 13:21   ` Jonathan Cameron
2026-04-17 17:36 ` [PATCH 6/9] iio: mcp9600: " Yury Norov
2026-04-19 13:21   ` Jonathan Cameron
2026-04-17 17:36 ` [PATCH 7/9] wifi: rtw89: " Yury Norov
2026-04-20  7:49   ` Ping-Ke Shih
2026-04-20 17:59     ` Yury Norov
2026-04-17 17:36 ` [PATCH 8/9] rtc: rv3032: " Yury Norov
2026-04-17 17:36 ` [PATCH 9/9] ptp: " Yury Norov
2026-04-17 18:23 ` [PATCH 0/9] bitfield: add FIELD_GET_SIGNED() Andy Shevchenko
2026-04-17 19:21   ` Yury Norov
2026-04-24 12:09 ` Jonathan Cameron
2026-04-24 15:50   ` Yury Norov
2026-04-24 17:10     ` Yury Norov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260427104252.5203a50e@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=mingo@redhat.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=ynorov@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox