Re: flag day for 64-bit?

> At soem time we will want this, I can look it up and repost it here, and
> enter it into the savannah task manager.

Sounds good.

> If there are more I forgot about them, so they are probably not important.

Ok.  I wonder if there is some way we can make the dpkg dependency magic
flag them for us (i.e. anything that depended on the old hurd package).
Ideal would be something that prevented their installation.  But you could
certainly just examine the extant package set for that dependency to be
sure what to recompile (or even make the new hurd pkg conflict with those
individual old pkgs?).

> Lemme just quote the relevant part of your original roadmap, 

Yeah, yeah.  That's it.  I had a *plan*.

> "* Step 2: This step has no prerequisite steps, but doing it breaks things.
> A separate step is to add interfaces using 64-bit types.  I think
> everything relevant is in io.defs and fs.defs; Mark has already figured out
> the type definitions in libc (we are aiming to keep them as close as
> possible to the Linux/i386 types).  The only nonobvious RPC one might
> forget is io_identity, which for reasons I cannot recall returns st_ino and
> I don't know if that has become 64 bits.  I don't know if the dirent format
> has changed, in which case we'd need a new RPC."

dirent does indeed change because ino_t becomes ino64_t and is 64 bits.
This brings to mind something that I forgot to mention yesterday.  The
struct stat64 and statfs64 layouts that will now be the layouts of the RPC
arguments are not mig-friendly.  They contain some 64-bit members and some
smaller members, intermixed.  No Mach IPC type description for a single
object can actually represent them properly.  So the mig types I'll use
will be the right total size and can claim to be either 64 bit words or
twice as many 32 bit words, but receivers of different endianness would
still not get the contents unmangled correctly by a netmsgserver.  I am
completely happy with punting on that question, but I thought I should
mention it.  I simply accept that we won't have a usable netmsgserver
before we have different IPC and IDL technology altogether and can address
the whole question at a higher level.  I also accept that we don't have
complete mig-friendliness now, e.g. struct dirent which contains multi-byte
integer quantities in host order (u16 d_reclen, u32/u64 d_ino).  (I'm also
not entirely sure about struct procinfo any more.)

> This is then followed by a discussion about io_map, which we probably ignore
> for now :)  unless we can agree on the right interface for it today.

I've already stated several times that we're agreed on my plan.  At least
one of those times, Thomas said it would be acceptable.  So I am looking
moderately credible on that and probably that is what we will do.  We can't
fail to do anything at all unless we want to accept either another flag day
or getting the real compatibility plans into action before mmap64 will work
right.

> If we can agree on that, we could probably get the interface change in here
> for the future.  OTOH, changing the interface like this will require to
> change the code a bit to meet the new semantics (and in fact, the client has
> to do two RPCs if it wants a readable and a writable memory object - in case
> they are disjoint).

I am not sure what you are saying here.  The only thing that makes sense
(for mmap) is to say that the interface returns the max protection
available and if that doesn't include what the client asked for, then mmap
just fails.

> Getting io_map right at this stage would be nice, but it shouldn't really
> stop us, I think.

Agreed.  But I don't think it needs to slow us down.  The quoted new
interface is fine.  The corners of the semantics don't matter for now.  The
implementations right now will just not cope with new complexities and that
will be fine on the client side until we have new filesystem
implementations doing hairier things.  The only server that might support
mmap of a large file soon is storeio on disk partitions, and we can cope
for a while if mmap hits an assert for a span across a 4GB alignment boundary.


So, I tried a build with -D_FILE_OFFSET_BITS=64 and it went quite smoothly.
So I now think that's the right thing to do.  The exported Hurd header
files like store.h et al can be made LFS-aware so that they work in that
mode and also in 32-bit mode with their interfaces using struct stat64 et al.