On Mon, 12 Apr 2021 11:43:02 +0200,
Jaroslav Kysela wrote:
>
> Dne 12. 04. 21 v 11:31 Takashi Iwai napsal(a):
> > On Sun, 11 Apr 2021 19:52:21 +0200,
> > Jaroslav Kysela wrote:
> >>>>> struct snd_rawmidi_params {
> >>>>> int stream;
> >>>>> size_t buffer_size; /* queue size in bytes */
> >>>>> size_t avail_min; /* minimum avail bytes for wakeup */
> >>>>> unsigned int no_active_sensing: 1; /* do not send active sensing byte in close() */
> >>>>> - unsigned char reserved[16]; /* reserved for future use */
> >>>>> + unsigned char framing; /* For input data only, frame incoming data */
> >>>> We can move this flag to above 32-bit word (no_active_sensing). I'm not sure,
> >>>> if we need 8 bits for this. It's first change after 20 years. Another flag may
> >>>> obsolete this one.
> >>>
> >>> Not sure what you mean by this, could you show the code? Framing is an
> >>> enum rather than a flag, in case we find other framing formats with
> >>> other sizes that would obsolete this one.
> >>
> >> unsigned int no_active_sensing: 1;
> >> unsigned int framing32: 1;
> >> unsigned int framing64: 1; /* future extension, framing32 == 0 in this case */
> >>
> >> or:
> >>
> >> unsigned int framing_mode: 3; /* three bits for future types */
> >>
> >> perhaps also:
> >>
> >> unsigned int clock_type: 3; /* three bits for the clock type selection */
> >
> > The usage of bit fields in an ioctl struct is a bad idea from the
> > compat layer POV. Let's avoid it.
>
> What exactly do you mean?
The compat layer has the hard time to deal with the conversion of bit
fields to a different struct. And, it's a nightmare for the emulator
like QEMU. If it has to convert the ioctl struct, it has to consider
about the byte order as well (and there is no strict definition how to
put the bit fields in C language).
That said, a bit field can be useful for the internal object
definition (if there is no racy access), but not for an object for the
communication that may be interpreted among different architectures.
Takashi
