That's why I had the new flags through a pointer also: not only can the
pointer be NULL, but it implies that we can more easily extend the set of
bits.
HOWEVER. I don't think we want all that many bits at all. My preferred
suggestion is to go with
u32 generic_bits;
u32 fs_bits;
and NOTHING more. Otherwise we'll just encourage people to go crazy with
the bits, and I do not want that.
(This is why I hate code that tries to be too generic and take everything
into account - it's not the code that is bad, but it's the _implication_
of the code that I dislike).
In fact, maybe we should codify it with a structure:
struct file_flags {
unsigned int generic_flags;
unsigned int fs_specific_flags;
};
and just pass in the structure pointer.
> Hmm... Methink I know what should be done here:
> chflags(name, level, old, new) where level being either FL_VFS or
> FL_EXT2 or FL_UFS, etc. IOW, the scheme similar to setsockopt().
I would not be disappointed with that kind of approach either. But if so,
do limit the flags to 32 bits (and then if somebody _really_ wants to go
wild, he can just specify multiple "levels").
Oh, and if you do this, please reserve leves 0-255 or something like that
for "generic" flags. I may not like excessive generic features, but if
done, they should at least be done _right_.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/