[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m11wqf12hh.fsf@ebiederm.dsl.xmission.com>
Date: Wed, 13 Sep 2006 22:44:26 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "Albert Cahalan" <acahalan@...il.com>
Cc: torvalds@...l.org, jeremy@...p.org, mingo@...e.hu, ak@...e.de,
arjan@...radead.org, zach@...are.com, linux-kernel@...r.kernel.org
Subject: Re: Assignment of GDT entries
"Albert Cahalan" <acahalan@...il.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists