Re: flag day for 64-bit?

[Thomas Bushnell, BSG]

Marcus Brinkmann <address@hidden> writes:

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

This cannot be done without *major* server pain.

Suppose we have two users, each asking for maximal memory objects (for
which SIZE is the maximum size of a memory object).

One asks for an offset of 0, the other asks for an offset of 1024. 

The manager will be obliged to provide *two* *different*
objects--because no single object could hold both ranges, since the
union is larger than the maximum allowed size.

But the objects share pages, which means we have identical file pages
being shared between two memory objects.

There is *NO* *WAY* to do this cleanly in the Mach VM interface, and
the unclean ways that do it correctly are:

1) Very inefficient, and
2) Very hairy.

It's much much much easier if we allow the server to tell the user:

"You get this part from one object, and that part from this other
object."  Then the server can guarantee that every page of the file
exists in one and only one object.

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

If we provide this relaxation, then this interface is tolerable.