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
