Sender: tech-kern-owner@netbsd.org

On Sun, 27 Jun 1999, Alexander Viro wrote:

> 
> 
> On Sun, 27 Jun 1999, Bill Sommerfeld wrote:
> 
> > > Usage of ioctl() on Linux was a bad idea and it's going to be fixed. More
> > > or less in the same direction, not exactly the same - 4.4 chflags() works
> > > fine for UFS and leaves other filesystems to map what they can into the
> > > UFS set. 
> > 
> > > Which is bogus - immutable is not a UFS attribute, it's VFS one.
> > 
> > Well, I'd argue that Berkeley defined a bunch of VFS attributes, and
> > then implemented them natively in UFS and LFS; other non-native
> > filesystems have to map their concepts of other file attributes (e.g.,
> > dates, permissions, etc.,) into the native VFS concepts.
> 
> 	Right. Except that UFS has not only generic attibutes. For example,
> you have UF_NODUMP and SF_ARCHIVED. The *only* place in the /sys you
> mention the former is sys/stat.h (BTW, you don't even map it on
> EXT2_NODUMP_FL). The latter is mentioned only in the msdosfs/msdosfs_vnops.c.
> Hardly a VFS flag, right?
> 	Proposed API on the Linux side being
> int chflags(name, level, oldp, newp); where level is FL_VFS for generic
> attirbutes (fs may map them on its own set) and FL_{UFS,EXT2,...} for raw
> flags - corresponding filesystem is free to interpret the thing as it
> likes and should set the generic attributes in the right way. If you are
> trying to talk with the wrong filesystem (i.e. the level is not FL_VFS and
> not FL_<filesystem_where_the_object_sits>) you are getting an error. If
> oldp is not NULL *oldp contains the attributes to set. if newp is not
> NULL *newp will contain the attributes *after* operation. IMO it's cleaner
> than pushing all attributes into the single bitmap.

This looks viable as long as you don't use small integers to represent
FL_UFS etc. Having a single header defining constants for all filesystems
just doesn't scale at all.

You still want a clearly defined set of FS independant flags so that the
application doesn't need to care what filesystem it is sitting on.

--
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 181 442 9037



-
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/