Re: [PATCH] print_dev_t for 2.6.0-test1-mm

From: Andries Brouwer <aebr@win.tue.nl>
To: Andries Brouwer <aebr@win.tue.nl>, Andrew Morton <akpm@osdl.org>,
	miquels@cistron.nl, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] print_dev_t for 2.6.0-test1-mm
Date: Fri, 18 Jul 2003 03:05:58 +0200	[thread overview]
Message-ID: <20030718030558.B2612@pclin040.win.tue.nl> (raw)
In-Reply-To: <20030718000444.GG19891@ca-server1.us.oracle.com>; from Joel.Becker@oracle.com on Thu, Jul 17, 2003 at 05:04:45PM -0700

On Thu, Jul 17, 2003 at 05:04:45PM -0700, Joel Becker wrote:

> 	Yes, but there is a nice simplicity in saying filesystems that
> support 64bit device numbers get the expanded space, and filesystems
> that cannot are limited to 16bits.  Most modern systems would have an
> updated set of filesystems.  All pre-existing filesystems have only
> 16bit device numbers.  All new mknod64() calls will only work on
> filesystems that can store 64bits.

You are an optimist.
My transition is much slower - I am a slow kind of person.

There is no flag day. The kernel must be updated, glibc must be
updated, user space software must be updated. A long process
that will take years. Indeed, so far we have not succeeded in
updating the kernel, and eight years went by.

Filesystems? Last I looked reiserfs handled 32 bits.

Really, we need the three stages - if the middle 32-bit stage
is absent too much software breaks. We must go forward slowly.

Andries