From owner-freebsd-hackers Sun Jun 27 10:15: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 0977C14C23 for ; Sun, 27 Jun 1999 10:15:04 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id SAA28770; Sun, 27 Jun 1999 18:17:35 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 27 Jun 1999 18:17:34 +0100 (BST) From: Doug Rabson To: Alexander Viro Cc: Bill Sommerfeld , Francois-Rene Rideau , Linux Kernel , FreeBSD Hackers , NetBSD Kernel Subject: Re: Improving the Unix API In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.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_) 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