Messages in this thread | | | Date | Fri, 25 Jun 1999 13:36:38 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [RFC] File flags handling - proposal for API. |
| |
On Fri, 25 Jun 1999, Linus Torvalds wrote:
> No, just make it do > > {l,f,}chflags({name,fd,name}, u32 *old, u32 *new); > > and then you can read and write the flags with just one system call. I do > not want to extend on stat() yet again.
OK. But there is one but - we definitely have flags on ext2, ufs and <urgh> FAT ("System" == Immutable). I'm more than sure that other filesystems will join too - we are risking to run out of bits if we will go for plain union and we will get the whole lot of nasty bit-shuffling in bargain. I still think that distinction between generic and fs-specific deserves to be done in API. I.e. we are either passing raw attributes and then the result is fs-specific (and it's fs responsibility to recalculate generic attributes) or we are interested in generic attributes and then we don't want to mess with fs differences. <generic> + <ext2-specific> + <ufs-specific> + ... in one bitmap will lead to major PITA. <generic vs. raw> + {<generic attributes> | <attributes of whatever fs it sits on>} will give us decent bandwidth and make extensions *much* easier. 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(). Comments? That way we would get an additional safety - if the call is done for the object on wrong fs it will return -ENOPROTOOPT ;-) IMO it's cleaner and will reduce the future clutter. 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/
| |