"Stephen C. Tweedie" wrote:
I have to admit that when I first looked at your proposal I thought it
was overkill, but having followed the thread all the way through I now
have some appreciation of the weird wacky world out there that you are
dealing with. I think your approach is correct. Here are some nits re
your attrib structure.
Nit 1: Do you really need a per-attribute name family? Nit 2:
int-aligned should be good enough for this - I doubt you'll get any
measureable improvement in cache performance with long alignment; int
alignment takes care of alignment-challenged archs and gets 90% of the
cache efficiency. Nit 3: If you make it a *rule* that the record has to
be aligned you don't need the rec_len and it's probably microscopically
faster to traverse anyway because you load one less variable and do the
computation entirely in registers instead (p+=-p&3). Nit4: Do you want
the ints to be native-word-sized or fixed-word-size? Since it's a
filesystem interface I'd think fixed. The result is:
struct attrib {
u32 name_len;
u32 val_len;
char name[variable];
char val[variable];
};
This is considerably easier on my eyes, YMMV. Since you've allowed for
names to be up to 4 gig long I'd think there's room in there for a
per-attribute namespace in the unlikely event the attribute familly
needs it.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
