Date: Sun, 27 Jun 1999 13:36:26 -0400 (EDT) From: Alexander Viro <viro@math.psu.edu> To: Doug Rabson <dfr@nlsystems.com> 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.GSO.4.10.9906271322421.24019-100000@weyl.math.psu.edu> In-Reply-To: <Pine.BSF.4.05.9906271814420.80685-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 - <sys/stat.h> and there you go. If you need some particular fs - <sys/stat.h> and <sys/foo_fs.h> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.9906271322421.24019-100000>