From owner-freebsd-hackers Sun Jun 27 16:19:24 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 9664D14ECD for ; Sun, 27 Jun 1999 16:19:20 -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 AAA29423; Mon, 28 Jun 1999 00:21:56 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 28 Jun 1999 00:21:55 +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, 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 I'm talking about the concept of a header file containing something like: #define FL_VFS 0 #define FL_FOOFS 1 #define FD_BARFS 2 ... not being scalable. Do you have a complete list of filesystem types? Are you prepared to act as an Assigned Number authority for that list. For this kind of problem, strings are a damn sight easier to manage in the long term. > > > 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. I'm sure the api would be easy to port. I wouldn't accept any api for FreeBSD which involved assigning numbers to filesystem types. It was too painful to rid it of the last set of numbers from the old mount(2) call. -- 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