Re: flag day for 64-bit?

[Marcus Brinkmann]

On Fri, Jun 07, 2002 at 04:02:31AM -0400, Roland McGrath wrote:
> is ABI compatibility for libhurduser, for which I have previously
> described some scheme for automating the use of symbol versions with
> mig stubs that I don't really remember and am too lazy to go look up
> (but which is probably not so hard to actually implement).

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

> So ... what if we just punted all that and had a flag day? 

Thumbs up.  There are some native Hurd programs that are not part of the
Hurd.  start-stop-daemon only links to libps, so no problem there.
um-pppd does some RPCs, but it has not yet been compiled for the
libio-based system, so no problems there either :)

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

Lemme just quote the relevant part of your original roadmap, so we don't
forget anything:

"* 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."

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 think the only RPC whose new form is not obvious is io_map.  Thomas made
some suggestions in the past I didn't care for.  What I would like to see
is:

routine io_map (
        io_object: io_t;
        in file_offset: off64_t;
        out memobj_offset: vm_offset_t;
        inout size: vm_size_t;
        inout max_prot: vm_prot_t;
        out memobj: mach_port_send_t);

The idea here is that the client gives a range of the file and protection
they want to map, and the server returns a memory object that covers at
least that much.  The server can decide how to organize its memory objects
however it likes.  The out parameters inform the client of the (possibly
larger and differently aligned) range of the returned memory object that
correspond to the region of the file it requested.  The server must provide
a single memory object that covers the whole range to be mapped--perhaps we
could relax this to require the client to do separate mappings if the
returned region is smaller than what it requested."

AFAIR, everyone was happy with this interface, as it allowed the server
either to do it the R-way or the T-way, *if* you indeed allow the server to
return a memory object that covers the beginning of the io object, requiring
the caller to do multiple mappings.

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).

> Unless I'm overlooking something, we could hack this up in a day and
> then throw into debian new libc and hurd packages requiring each other
> and conflicting with older ones and that would be that and noone would
> even notice the incompatibility go by.

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

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de