Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: Assignment of GDT entries | Date | Wed, 13 Sep 2006 22:44:26 -0600 |
| |
"Albert Cahalan" <acahalan@gmail.com> writes:
> I think that would be a lower chance, not a greater chance. > Reasons why an app might care: > > a. identify a 64-bit kernel > b. far jumps between 32-bit and 64-bit code > c. reload of ds/es after a string operation on thread-private data > > Perhaps i386 should change to match x86_64.
I agree that the difference is annoying.
However I just wrote a user space implementation of fork that is capable of copying a process from an i386 only kernel to a x86_64 kernel, and executing there without having to detect the kernel type.
It didn't takes hacks to accomplish that.
The basic syscall is: int set_thread_area (struct user_desc *u_info); struct user_desc { unsigned int entry_number; unsigned long base_addr; unsigned int limit; unsigned int seg_32bit:1; unsigned int contents:2; unsigned int read_exec_only:1; unsigned int limit_in_pages:1; unsigned int seg_not_present:1; unsigned int useable:1; };
If entry_number is -1 the kernel finds a free gdt entry and sets up the segment and returns with entry_number set to the segment number.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |