lkml.org 
[lkml]   [1999]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.088 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site