[Ocfs2-devel] [PATCH 1/2] ocfs2-tools: Add extended attribute support in mkfs.ocfs2
Joel Becker
Joel.Becker at oracle.com
Tue Jul 29 15:23:02 PDT 2008
On Tue, Jul 29, 2008 at 01:49:52PM +0800, Tiger Yang wrote:
> Joel Becker wrote:
>
> >> +struct ocfs2_xattr_entry {
> >> + __le32 xe_name_hash;
> >> + __le16 xe_name_offset;
> >> + __u8 xe_name_len;
> >> + __u8 xe_type : 7;
> >> + __u8 xe_local : 1;
> >> + __le64 xe_value_size;
> >> +};
> >
> > We removed the bitfields.
>
> Do we really remove the bitfields? We have no space for new u8 in
> xattr_entry.
> Mark said we just need change the bottom bit for xe_local.
We don't add an extra u8. We just define the single u8 and will
use masking to flag out the local bit.
Here's the structure:
struct ocfs2_xattr_entry {
__le32 xe_name_hash;
__le16 xe_name_offset;
__u8 xe_name_len;
__u8 xe_type;
__le64 xe_value_size;
};
And you'd access xe_type with something like this:
static inline int xe_get_type(struct ocfs2_xattr_entry *xe)
{
return xe->xe_type & 0xFE;
}
static inline int xe_is_local(struct ocfs2_xattr_entry *xe)
{
return xe->xe_type & 0x01;
}
Something like that. Mark might have a preferred way to create
the accessor functions. The point is, defining the bitfields (:7, :1)
isn't a portable thing to do for on-disk structures.
Joel
--
"I'm so tired of being tired,
Sure as night will follow day.
Most things I worry about
Never happen anyway."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
More information about the Ocfs2-devel
mailing list