On Tue, Oct 03, 2023 at 04:37:01PM -0700, Nuno Das Neves wrote:
> On 9/30/2023 11:19 PM, Greg KH wrote:
> > On Sat, Sep 30, 2023 at 10:01:58PM +0000, Wei Liu wrote:
> > > On Sat, Sep 30, 2023 at 08:09:19AM +0200, Greg KH wrote:
> > > > On Fri, Sep 29, 2023 at 11:01:39AM -0700, Nuno Das Neves wrote:
> > > > > +/* Define connection identifier type. */
> > > > > +union hv_connection_id {
> > > > > + __u32 asu32;
> > > > > + struct {
> > > > > + __u32 id:24;
> > > > > + __u32 reserved:8;
> > > > > + } __packed u;
> > > >
> > > > bitfields will not work properly in uapi .h files, please never do that.
> > >
> > > Can you clarify a bit more why it wouldn't work? Endianess? Alignment?
> >
> > Yes to both.
> >
> > Did you all read the documentation for how to write a kernel api? If
> > not, please do so. I think it mentions bitfields, but it not, it really
> > should as of course, this will not work properly with different endian
> > systems or many compilers.
>
> Yes, in https://docs.kernel.org/driver-api/ioctl.html it says that it is
> "better to avoid" bitfields.
>
> Unfortunately bitfields are used in the definition of the hypervisor
> ABI. We import these definitions directly from the hypervisor code.
So why do you feel you have to use this specific format for your
user/kernel api? That is not what is going to the hypervisor.
> In practice the hypervisor, linux, and VMM compilers all produce the
> same layout for bitfields on the architectures we support.
You are getting lucky, please do this properly, without a bitfield
marking in the structure.
thanks,
greg k-h
