Messages in this thread | | | Date | Fri, 25 Jun 1999 14:26:42 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [RFC] File flags handling - proposal for API. |
| |
On Fri, 25 Jun 1999, Linus Torvalds wrote:
> 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.
Oho... fchflags == setsockopt? It may make sense, but... definitely queer.
> HOWEVER. I don't think we want all that many bits at all. My preferred Oh, yes. > 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).
<AOL></AOL> We are *not* bound by "GNU coding style". Featuritis is *bad* thing and supporting it... No, thanks.
> 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_.
OK, I'll go for that variant. Unless we want to overload {set/get}sockoptions and add missing calls to the set. Dunno... while this has some merit (essentially we want the same kind of control with s/protocol family/filesystem/ and s/SOL_SOCKET/FL_VFS/, moreover, some fcntl() applications could find the place in the same space) I'm *not* sure that it's good. It would make more sense if we didn't have old binaries around and could kill ioctl(2) and friends for good. -ENOSUCHLUCK... Up to you. I think that chflags(name, level, old, new) is the right variant, so unless you are *really* interested in extending setsockopt() API to files I'll go for it. Comments?
- 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/
| |