Date: Sun, 27 Jun 1999 13:02:39 -0400 (EDT) From: Alexander Viro <viro@math.psu.edu> To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> Cc: 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.GSO.4.10.9906271238590.24019-100000@weyl.math.psu.edu> In-Reply-To: <199906271628.QAA22753@orchard.arlington.ma.us>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.GSO.4.10.9906271238590.24019-100000>