Date: Mon, 11 Mar 2002 22:20:35 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Garance A Drosihn <drosih@rpi.edu> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Terry Lambert <tlambert2@mindspring.com>, Harti Brandt <brandt@fokus.gmd.de>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <Pine.NEB.3.96L.1020311221258.50635D-100000@fledge.watson.org> In-Reply-To: <p05101550b8b310e6cfae@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Mar 2002, Garance A Drosihn wrote:
> So, as far as userland stat() goes, a 64-bit inode is pretty easy, but I
> would like to see us set the stage for the other things we keep talking
> about. All of those require a bigger struct-stat, and I can't think of
> any pretty way of doing that and also maintaining binary compatibility.
> Let us pretend that we "absolutely had to" increase the struct, *and* we
> could not break binary compatibility, *and* we would maintain posix
> compatibility for anything which was simply recompiled. If we had to do
> all three of those, how could we do it?
My personal feeling on this is that 5.0 is a good time to "take the leap".
We know we need to roll the on-disk data structures to support UFS2, we're
changing a number of other APIs (shortly including many of the SysV IPC
APIs to properly support 32-bit uids and gids). We're completely
replacing the threading mechanism, changing many of the APIs for library
cals, we've added support for extended attributes, ACLs, etc. Now is the
time. The longer the wait, the harder it gets. :-)
As to the migration path: your suggestion sounds fine. I'd be tempted to
simplify the approach:
(1) Provide compatibility system calls in the style of ofoo() providing
the 32-bit versions, and make sure that the compatibility libc (and so
on) use those.
(2) Modify inode.h to look like what we want it to end up looking like,
and define new system calls using the native names (stat(), et al).
Avoid providing source structure compatibility where it only serves to
cause code to use the wrong types without warnings.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020311221258.50635D-100000>