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.

    Alexander Viro writes:
    > 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.

    With *old and *new being what? Raw fs-specific inode data?
    Something with a version number or size?

    > 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

    FAT has attributes like "MICROS~1.HTM". NTFS has a 4th time stamp.
    HFS has type and creator data.

    > 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().

    Um, might there be a VFS already? As in "mount -t vfs..."?
    There are already at least 3 XFS filesystems. FL_GENERIC is
    less likely to be a filesystem name.

    Oh, be sure to use a 64-bit inode if you return that data.

    -
    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.028 / U:60.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site