On Thu 27-04-23 22:11:46, Amir Goldstein wrote:

On Thu, Apr 27, 2023 at 7:36 PM Jeff Layton [off-list ref] wrote:

quoted

quoted

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 [off-list ref]
SUSE Labs, CR