Re: 64bit GNU Mach

[Samuel Thibault]

Richard Braun, le Mon 02 Apr 2012 14:44:45 +0200, a écrit :
> On Mon, Apr 02, 2012 at 02:39:05PM +0200, Samuel Thibault wrote:
> > > I don't see the relation with segmentation and the 4GiB split.
> > 
> > I said: "to avoid the trick", i.e. just use 32bit pointers, to just use
> > the same type as in userland as you suggested.
> > 
> > > What is the layout you expect for the kernel space ? First 4 GiB user
> > > then kernel ?
> > 
> > First 4GiB user, last 4GiB kernel.
> > 
> > > And you thought of segmentation to implicitely shift addresses ?
> > 
> > Again, there is no segmentation in x86_64.
> 
> I was wondering why you referred to segmentation in the first place.
> I guess segmentation is what you referred to as "the trick".

No, I mentioned segmentation as the way to have both kernel and user
being able to use 4GiB pointers without limiting themselves in the same
linear address area.

> > > IMHO, changing GNU Mach to cleanly convert port names where needed
> > > remains the sane choice.
> > 
> > That is, use 32bit port names for userland, and convert to 64bit port
> > addresses for kernelland. But that can only work if using different
> > types.
> 
> I believe we're thinking of two different things here. My current idea
> of the solution is to directly convert names (32-bits) to ports or other
> IPC objects (e.g. port sets, 64-bits).

That's what I'm suggesting from the beginning. That needs two differents
types (64bit mach_port_t and 32bit mach_port_name_t), where there is
currently just one (vm_offset_t mach_port_t).

> You may be thinking of converting user names (32-bits) to kernel names
> (64-bits), then kernel names to IPC objects. Am I right ?

No, I thought you were suggesting to convert usernames (32bits) to
kernel pseudo-pointers (32bit), then use some trick to convert these to
real pointers (64bit).

Samuel