From owner-freebsd-arch Wed Feb 28 17:11:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 1ED7F37B718 for ; Wed, 28 Feb 2001 17:11:17 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f211A3J01588; Wed, 28 Feb 2001 17:10:03 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f211A2843934; Wed, 28 Feb 2001 17:10:02 -0800 (PST) (envelope-from jdp) Date: Wed, 28 Feb 2001 17:10:02 -0800 (PST) Message-Id: <200103010110.f211A2843934@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: scott_long@btc.adaptec.com Subject: Re: Arch question for a UDF FS driver In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Long, Scott wrote: > I've starting writing a UDF FS driver for FreeBSD, and am coming to a > decision point. UDF is somewhat similar to ufs in that a File Entry is > analogous to an inode, so I'd like to implement the filesystem using the > vget vfsop. Problem is that vget uses ino_t which is a uint32_t, while the > Unique Id (aka inode number) for UDF is a uint64_t. Unique Id's are > numbered sequentially starting at 16 (0 is the root dir, 1-15 are reserved), > and may be sparse. So what color should I paint the bikeshed? [...] > Orange: Get ino_t bumped up to a uint64_t and modify all the other > filesystems to deal with it accordingly. Advantage: no hackery needed for > UDF. Disadvantage: may be the mother of all bikesheds. Unfortunately, values of type ino_t are passed from kernel to userland via the stat(2) family of system calls. So if you change the size of ino_t, it will change the shape of the stat structure. This would introduce binary compatibility problems. There would have to be yet another flavor of struct stat (we already have 3 of them in ), and some new system calls for the new versions of stat(), fstat(), and lstat(). I.e., you can't just change the existing system calls without totally breaking old binaries. It's not a total show-stopper, but it does make that shade of orange look kind of, er, puke colored. :-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message