On Thu 27-04-23 22:11:46, Amir Goldstein wrote:
> On Thu, Apr 27, 2023 at 7:36 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> > > There is also a way to extend the existing API with:
> > >
> > > Perhstruct file_handle {
> > > unsigned int handle_bytes:8;
> > > unsigned int handle_flags:24;
> > > int handle_type;
> > > unsigned char f_handle[];
> > > };
> > >
> > > AFAICT, this is guaranteed to be backward compat
> > > with old kernels and old applications.
> > >
> >
> > That could work. It would probably look cleaner as a union though.
> > Something like this maybe?
> >
> > union {
> > unsigned int legacy_handle_bytes;
> > struct {
> > u8 handle_bytes;
> > u8 __reserved;
> > u16 handle_flags;
> > };
> > }
>
> I have no problem with the union, but does this struct
> guarantee that the lowest byte of legacy_handle_bytes
> is in handle_bytes for all architectures?
>
> That's the reason I went with
>
> struct {
> unsigned int handle_bytes:8;
> unsigned int handle_flags:24;
> }
>
> Is there a problem with this approach?
As I'm thinking about it there are problems with both approaches in the
uAPI. The thing is: A lot of bitfield details (even whether they are packed
to a single int or not) are implementation defined (depends on the
architecture as well as the compiler) so they are not really usable in the
APIs.
With the union, things are well-defined but they would not work for
big-endian architectures. We could make the structure layout depend on the
endianity but that's quite ugly...
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
