roadmap for 64-bit file io support

[Roland McGrath]

I don't actually have a roadmap in this message. 
I'm starting the thread in hopes that one will come together.

There isn't any "hard work" to be done for 64-bit io protocols.  The only
thing that borders on nontrivial by itself is io_map, and that could even
just be put off in the first cut.  The only immediate usefulness of 64-bit
io protocols is for storeio access to large disks and partitions.  Those
uses can live without io_map working at all, and regular file uses can live
with using the old io_map protocol (since we don't have a filesystem that
can support a file >2GB yet anyway).  

The first thing we need is a good RPC versioning scheme.  I recently
reposted here an old message describing a plan for that.  We could
implement that and put the new versioned stub libraries into glibc-2.3,
which will be forking from stable glibc-2.2 pretty soon.  Probably it would
be safe enough that I'd put it in 2.2 as well.

As soon as we have the Hurd half of the RPC versioning scheme, we can write
libiohelp/libfshelp code to support the compat (current) RPCs in terms of
the new stub functions, and convert the server code to the new argument
types.  All those changes are easy to do and hard to get wrong.

As soon as we have the libc half of the RPC versioning scheme, we can have
the new stubs in libhurduser.  Then we convert the libc code to use the new
stubs and fall back to compat stubs for old interfaces, which is also easy.

With just those steps, we should have a pretty smooth conversion.  The
libc.so ABI should not have to change at all, and the versioned libhurduser
will be compatible with any old code.  The only ABIs that should be broken
are those of the Hurd server libraries, and we have generally not had
problems requiring wholesale updates of Hurd libs and everything using them.
Or we could choose this conversion time to bump the sonames to 0.3.

We could design the details of the .defs versioning macros so that it's
possible to update the .defs files and use those to build a new libc, while
also being able to compile old, unchanged hurd code from those .defs files.
But the transition shouldn't take long, so it's probably easiest just not
to worry about the halfway states of the source code.  We can first change
the .defs files and work on libc while using old installed hurds and
relying on libc's compat fallback during the period when the hurd source
tree can't be compiled.