On Mon, 18 Sep 2023, Luck, Tony wrote:
> > I think Tony's "proof" is pretty invalid. He doesn't differentiate
> > HW interface related bitfields from those which are not HW interface
> > related (to the extent that in fact most of those bitfields likely are not
> > HW interface related).
>
> When I made that comment it was about a patch series that used
> bitfields to decode the subfields in Intel model specific MSRs. I
> think that's true of use in this series too.
But your grep in [1] was not limited to such cases nor to HW interface
related ones in general.
What I meant with your proof being invalid is that the argument against
bitfields have been related to using them with HW interfaces, not just
generic use of the bitfields (even if there have been some performance
issues in that area as well). Simply grepping through include/ directly is
not going to tell anything if the bitfield in question is related to HW
interfaces or not.
> I think most of these are for MSR decode. The one mentioned in
> this thread: "union ifs_scan_hashes_status_gen2 {" definitely is.
>
> Are there any that are not for MSRs? I'd also claim "Intel
> specific" if there are some decoding parts of the Intel scan
> file format.
First of all, I already checked myself that the alignment is not
incorrect so I don't find it as problematic as I thought it was (I did
not even flag all bitfield addition in the patches, just the cases were u8
was followed by u32 bitfield which I thought is not going to work because
of something I read about this topic some time ago claimed if the type
changes the bitfield does not carry over).
Since you replied, would you happen to have a pointer something that tells
(in writing) how the bitfields in C are allocated in case of x86_64? I
spent a bit of time trying to find something but came up nothing.
[1] https://lore.kernel.org/lkml/SJ1PR11MB6083EBD2D2826E0A247AF242FCD19@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
--
i.
