Date: Sun, 27 Jun 1999 18:17:34 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Alexander Viro <viro@math.psu.edu> Cc: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>, Francois-Rene Rideau <fare@tunes.org>, Linux Kernel <linux-kernel@vger.rutgers.edu>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, NetBSD Kernel <tech-kern@netbsd.org> Subject: Re: Improving the Unix API Message-ID: <Pine.BSF.4.05.9906271814420.80685-100000@herring.nlsystems.com> In-Reply-To: <Pine.GSO.4.10.9906271238590.24019-100000@weyl.math.psu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9906271814420.80685-100000>