On Mon, Oct 30, 2000 at 02:39:27PM -0800, Ulrich Drepper wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > Fair enough. However, the question still remains if we should make it
> > the default and make the old heterogenous API the explicit option.
>
> Sure, this can be done. When the time comes. Certainly not in glibc
> 2.2. This always was the plan and since the old functions will not be
> removed and the LFS interfaces will not be renamed there will be no
> compatibility issues. I.e., no programs using stat() will reference
> stat64.
We had this 64-bits-or-not discussion with Ulrich back when 2.1 was
imminent, and he was utterly convinced that it is good to save space
at various LFS related structure fields. Now that is coming to haunt
us... (I distinctly recall of him mentioning of receiving "authoritative
advice" that 32 bits will be enough for inode numbers.)
Also, I am sad to say, latter Linus thought that having inferior kernel
ABI in form of inadequate struct stat64 of glibc 2.1+ was better to
support at kernel stat64(), than something with adequate field sizes
but userspace support being somewhat harder to make.
The more I am following this disaster called ABI evolution, the more
I am convinced that IBM did indeed do something right at the switch
from AIX 3.x to AIX 4.x -- ALL SCALAR INTEGERS AT AIX 4.x ABIs ARE 64 BIT !
Obviously they are able to run and support older binaries, too.
I could bet that IBM coders got fed up with "please tweak(*) this
interface from 16 to 32 bits, please tweak that interface from 8 to
16 bits" and next month continuing with "please tweak that to 32 bits,
last months customer deployed 16 bits one is inadequate", and cured it
by tweaking all possible interfaces in one go. ("tweak" => "enlarge" )
For some things even 64 bits are not enough (specifically some
cases of "inode number" at some filesystem types), but that is
something where I would let the FSes to create 64 bit "inode"
number reference instead of full internal btree reference, or
whatever. Although...
Naturally things like poll() parameter structure elements
carrying 64-bit fd numbers are mighty stupidly looking, but
the recent discussions about adding more of pollable events
do lead to thought that having shorts for event flags is
soon going to be serious hinderance...
struct pollfd {
int fd;
short events;
short revents;
};
Similar examples can be dug up all over.
Hmm.. Like getgroups() -- sure nobody will need group-id exceeding
say 16 bits ? Ah well, 32 bits will surely be enough for all ?
Yeah, really ? As things are bound to happen, somebody will come
up with really excellent reason for having 128 bit UIDs and GIDs right
the next day we release 64 bit ones.
Something along the lines of: As we no longer have access control
in form of having magic UIDs, e.g. zero vs. non-zero, we could as well
begin to use UTF-16 UNICODE 3.0 encoded strings for UID referral in
fixed size arrays giving us instant Java string compability.
(Ok, far fetched, but just you wait...)
> --
> ---------------. ,-. 1325 Chesapeake Terrace
> Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
> Red Hat `--' drepper at redhat.com `------------------------
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
