From owner-freebsd-hackers Sun Jun 27 10:36:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by hub.freebsd.org (Postfix) with ESMTP id 393631502E for ; Sun, 27 Jun 1999 10:36:29 -0700 (PDT) (envelope-from viro@math.psu.edu) Received: from weyl.math.psu.edu (weyl.math.psu.edu [146.186.130.226]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id NAA29133; Sun, 27 Jun 1999 13:36:27 -0400 (EDT) Received: from localhost (viro@localhost) by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id NAA02749; Sun, 27 Jun 1999 13:36:26 -0400 (EDT) X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs Date: Sun, 27 Jun 1999 13:36:26 -0400 (EDT) From: Alexander Viro To: Doug Rabson 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, Doug Rabson wrote: > 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 Erm... sizeof(int)==4. I doubt that you will need more. > just doesn't scale at all. Sure. If you don't need fs-specific stuff - and there you go. If you need some particular fs - and > 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. And that's exactly the reason for FL_VFS vs. FL_FOOFS separation - some applications should be able to talk with the filesystem in the filesystem's terms *and* be sure that they will not mess with another fs; the rest shouldn't care for fs differences at all (aside of "did the sucker set the bits I wanted?" that you already have for SUID/SGID/sticky). I don't think that porting it to 4.4 will be difficult - all you need is a way to tell VOP_SETATTR what level are you talking to (most likely the same way as on the our side - add a field to the structure and let the methods scratch their heads). I'm going to do the Linux variant and see how it will work. If somebody wants to do it with *BSD - fine, it shouldn't be a problem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message