Hi,
We made lots of progresses on x32 pABI:
https://sites.google.com/site/x32abi/
1. Kernel interface with syscall is close to be finalized.
2. GCC x32 branch is stabilizing.
3. The Bionic C library works with the syscall kernel interface.
The next major milestone will be x32 glibc port.
--
H.J.
* H. J. Lu:
> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
> 2. GCC x32 branch is stabilizing.
> 3. The Bionic C library works with the syscall kernel interface.
>
> The next major milestone will be x32 glibc port.
It is a bit difficult to extract useful information from these
resources.
Is off_t 32 bits? Why is the ia32 compatiblity kernel interface used?
I'm sure a lot of people want to get rid of that in cases where they
control the whole software stack.
Is stack alignment to 16 bytes beneficial for X32?
On Sat, Feb 12, 2011 at 1:10 PM, Florian Weimer <[email protected]> wrote:
> * H. J. Lu:
>
>> We made lots of progresses on x32 pABI:
>>
>> https://sites.google.com/site/x32abi/
>>
>> 1. Kernel interface with syscall is close to be finalized.
>> 2. GCC x32 branch is stabilizing.
>> 3. The Bionic C library works with the syscall kernel interface.
>>
>> The next major milestone will be x32 glibc port.
>
> It is a bit difficult to extract useful information from these
> resources.
That is true. Contributions are more than welcome.
> Is off_t 32 bits? ?Why is the ia32 compatiblity kernel interface used?
Yes.
> I'm sure a lot of people want to get rid of that in cases where they
> control the whole software stack.
That is debatable. The current thought is the x32 user space API
is the same as is ia32. time_t is also an issue.
> Is stack alignment to 16 bytes beneficial for X32?
>
Even ia32 uses 16byte stack alignment and we will make it
official soon via an amendment to the i386 psABI.
--
H.J.
On 02/12/2011 01:10 PM, Florian Weimer wrote:
> Why is the ia32 compatiblity kernel interface used?
Because there is no way in hell we're designing in a second
compatibility ABI in the kernel (and it has to be a compatibility ABI,
because of the pointer size difference.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sat, Feb 12, 2011 at 3:04 PM, H. Peter Anvin <[email protected]> wrote:
> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>> Why is the ia32 compatiblity kernel interface used?
>
> Because there is no way in hell we're designing in a second
> compatibility ABI in the kernel (and it has to be a compatibility ABI,
> because of the pointer size difference.)
I think he is asking why not create a new ABI layer for the kernel
like it is done for n32 for MIPS.
-- Andrew
* H. Peter Anvin:
> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>> Why is the ia32 compatiblity kernel interface used?
>
> Because there is no way in hell we're designing in a second
> compatibility ABI in the kernel (and it has to be a compatibility ABI,
> because of the pointer size difference.)
Actually, I'm wondering if you can do the translation in user space.
There already are 32-on-64 implementations in existence, without
kernel changes (recent Hotspot, LuaJIT, and probably some more).
On Sun, Feb 13, 2011 at 12:48 AM, Florian Weimer <[email protected]> wrote:
> * H. Peter Anvin:
>
>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>>> Why is the ia32 compatiblity kernel interface used?
>>
>> Because there is no way in hell we're designing in a second
>> compatibility ABI in the kernel (and it has to be a compatibility ABI,
>> because of the pointer size difference.)
>
> Actually, I'm wondering if you can do the translation in user space.
> There already are 32-on-64 implementations in existence, without
> kernel changes (recent Hotspot, LuaJIT, and probably some more).
Please check out the x32 kernel source and provide feedback.
--
H.J.
* H. J. Lu:
>> Actually, I'm wondering if you can do the translation in user space.
>> There already are 32-on-64 implementations in existence, without
>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>
> Please check out the x32 kernel source and provide feedback.
I still don't understand why you need a separate syscall table. You
should really be able to run on an unmodified amd64 kernel, in 64 bit
mode. This would imply that tools like strace don't need any porting
at all (you could just use the amd64 version), and even GDB would
mostly worked unchanged.
On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer <[email protected]> wrote:
> * H. J. Lu:
>
>>> Actually, I'm wondering if you can do the translation in user space.
>>> There already are 32-on-64 implementations in existence, without
>>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>>
>> Please check out the x32 kernel source and provide feedback.
>
> I still don't understand why you need a separate syscall table. ?You
> should really be able to run on an unmodified amd64 kernel, in 64 bit
That is done on purpose. x32 is designed for environments where the
current ia32 API is sufficient. You can think it as ia32 with register
extended to 64bit plus 8 more registers. Everything else is still 32bit.
> mode. ?This would imply that tools like strace don't need any porting
> at all (you could just use the amd64 version), and even GDB would
> mostly worked unchanged.
>
Yes, strace needs to be updated. I have ported GDB to x32.
--
H.J.
* H. J. Lu:
> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer <[email protected]> wrote:
>> * H. J. Lu:
>>
>>>> Actually, I'm wondering if you can do the translation in user space.
>>>> There already are 32-on-64 implementations in existence, without
>>>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>>>
>>> Please check out the x32 kernel source and provide feedback.
>>
>> I still don't understand why you need a separate syscall table. ?You
>> should really be able to run on an unmodified amd64 kernel, in 64 bit
>
> That is done on purpose. x32 is designed for environments where the
> current ia32 API is sufficient. You can think it as ia32 with register
> extended to 64bit plus 8 more registers. Everything else is still 32bit.
I think of it as amd64 where all the process memory happens to reside
in the first 4 GB of address space, and pointers are stored as 32 bits
(and you'd also reduce the size of longs because sizeof(long) !=
sizeof(void *) will break too many programs).
As I said, both LuaJIT and Hotspot are already using this model, with
custom memory allocators and a user-space translation layers, so I
still don't see what you get by changing the kernel. LuaJIT has even
implemented the amd64 ABI, so you can call C libraries from your
32-bit code. (Note that LuaJIT uses 64-bit words to store 32-bit
pointers with several tag bits, but it does so even on pure 32-bit
platforms.)
If you want to make x32 closer to i386, I don't see the point. Why
would it be problematic if it was as close to i386 as, say, armel?
On Sun, Feb 13, 2011 at 7:21 AM, Florian Weimer <[email protected]> wrote:
> * H. J. Lu:
>
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer <[email protected]> wrote:
>>> * H. J. Lu:
>>>
>>>>> Actually, I'm wondering if you can do the translation in user space.
>>>>> There already are 32-on-64 implementations in existence, without
>>>>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>>>>
>>>> Please check out the x32 kernel source and provide feedback.
>>>
>>> I still don't understand why you need a separate syscall table. ?You
>>> should really be able to run on an unmodified amd64 kernel, in 64 bit
>>
>> That is done on purpose. x32 is designed for environments where the
>> current ia32 API is sufficient. You can think it as ia32 with register
>> extended to 64bit plus 8 more registers. Everything else is still 32bit.
>
> I think of it as amd64 where all the process memory happens to reside
> in the first 4 GB of address space, and pointers are stored as 32 bits
> (and you'd also reduce the size of longs because sizeof(long) !=
> sizeof(void *) will break too many programs).
That is what the processor sees in an x32 program.
> As I said, both LuaJIT and Hotspot are already using this model, with
> custom memory allocators and a user-space translation layers, so I
> still don't see what you get by changing the kernel. ?LuaJIT has even
> implemented the amd64 ABI, so you can call C libraries from your
> 32-bit code. ?(Note that LuaJIT uses 64-bit words to store 32-bit
> pointers with several tag bits, but it does so even on pure 32-bit
> platforms.)
They can continue to do so.
> If you want to make x32 closer to i386, I don't see the point. ?Why
> would it be problematic if it was as close to i386 as, say, armel?
>
We are providing a 32bit API with 64bit registers. Current APIs support
either 32bit or 64bit. I am not talking about pointer or long. I am talking
other types, like time_t, off_t, ..., defined by API. Adding another API
is extremely difficult.
--
H.J.
On Sun, 13 Feb 2011, Florian Weimer wrote:
> >> Actually, I'm wondering if you can do the translation in user space.
> >> There already are 32-on-64 implementations in existence, without
> >> kernel changes (recent Hotspot, LuaJIT, and probably some more).
> >
> > Please check out the x32 kernel source and provide feedback.
>
> I still don't understand why you need a separate syscall table. You
> should really be able to run on an unmodified amd64 kernel, in 64 bit
> mode. This would imply that tools like strace don't need any porting
> at all (you could just use the amd64 version), and even GDB would
> mostly worked unchanged.
For the record -- I suggested a similar approach for n32 MIPS too (back
when it was on the table), but people rejected it deciding it was easier
for them to add a separate syscall table (for a change). It was perhaps
even more surprising as any MIPS 32-bit user pointer is a valid 64-bit one
too (I suspect this is also the case with x86-64) and any simple type,
including pointers and the "long long" type (such as used with lseek64(2),
etc.) goes into a single 64-bit register or stack slot with both ABIs, so
any conversion layer (boundary checks or whatever; structures can be
sorted out with padding) in libc would be pretty thin.
One argument in favour was the need of some people for crippled
interfaces such as original lseek(2) that would fail on large files for
the sake of some broken programs out there they wanted to rebuild for the
new ABI without fixing, sigh... Actually some OSes, such as NetBSD (I
think, it could have been one of the other *BSDs), do not offer these
crippled interfaces at all on any platform, but I gather people simply are
not particularly interested into pushing portability that far.
So now we have another table in the kernel to maintain that goes wrong in
respect to the two others from time to time. But there you go... At
least each of the three is optional. I couldn't care less about n32
anyway; I usually configure 64-bit MIPS kernels for n64 only.
Maciej
On Sun, Feb 13, 2011 at 7:43 AM, Maciej W. Rozycki <[email protected]> wrote:
> On Sun, 13 Feb 2011, Florian Weimer wrote:
>
>> >> Actually, I'm wondering if you can do the translation in user space.
>> >> There already are 32-on-64 implementations in existence, without
>> >> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>> >
>> > Please check out the x32 kernel source and provide feedback.
>>
>> I still don't understand why you need a separate syscall table. ?You
>> should really be able to run on an unmodified amd64 kernel, in 64 bit
>> mode. ?This would imply that tools like strace don't need any porting
>> at all (you could just use the amd64 version), and even GDB would
>> mostly worked unchanged.
>
> ?For the record -- I suggested a similar approach for n32 MIPS too (back
> when it was on the table), but people rejected it deciding it was easier
> for them to add a separate syscall table (for a change). ?It was perhaps
> even more surprising as any MIPS 32-bit user pointer is a valid 64-bit one
> too (I suspect this is also the case with x86-64) and any simple type,
> including pointers and the "long long" type (such as used with lseek64(2),
> etc.) goes into a single 64-bit register or stack slot with both ABIs, so
> any conversion layer (boundary checks or whatever; structures can be
> sorted out with padding) in libc would be pretty thin.
x32 is the same 64bit kernel interface for system calls which takes 64bit
arguments. You can pass either 32bit or 64bit value to them.
--
H.J.
On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer <[email protected]> wrote:
> > * H. J. Lu:
> >
> >>> Actually, I'm wondering if you can do the translation in user space.
> >>> There already are 32-on-64 implementations in existence, without
> >>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
> >>
> >> Please check out the x32 kernel source and provide feedback.
> >
> > I still don't understand why you need a separate syscall table. ?You
> > should really be able to run on an unmodified amd64 kernel, in 64 bit
>
> That is done on purpose. x32 is designed for environments where the
> current ia32 API is sufficient. You can think it as ia32 with register
> extended to 64bit plus 8 more registers. Everything else is still 32bit.
I think it would be great if you could add some text like this plus some
rationale (AIUI, this is geared mainly at new Atoms and other x86_64
embedded platforms) to the document.
(BTW, it is not really convincing to me that such a niche is worth all
the trouble this is going to bring.)
--
Petr "Pasky" Baudis
Computer science education cannot make an expert programmer any more
than studying brushes and pigment can make an expert painter. --esr
2011/2/13 Petr Baudis <[email protected]>:
> On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer <[email protected]> wrote:
>> > * H. J. Lu:
>> >
>> >>> Actually, I'm wondering if you can do the translation in user space.
>> >>> There already are 32-on-64 implementations in existence, without
>> >>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>> >>
>> >> Please check out the x32 kernel source and provide feedback.
>> >
>> > I still don't understand why you need a separate syscall table. ?You
>> > should really be able to run on an unmodified amd64 kernel, in 64 bit
>>
>> That is done on purpose. x32 is designed for environments where the
>> current ia32 API is sufficient. You can think it as ia32 with register
>> extended to 64bit plus 8 more registers. Everything else is still 32bit.
>
> I think it would be great if you could add some text like this plus some
> rationale (AIUI, this is geared mainly at new Atoms and other x86_64
> embedded platforms) to the document.
I updated:
https://sites.google.com/site/x32abi/
> (BTW, it is not really convincing to me that such a niche is worth all
> the trouble this is going to bring.)
>
That is a good question. Otherwise x32 would have been implemented
long time ago.
--
H.J.
On Sun, 13 Feb 2011, Petr Baudis wrote:
> I think it would be great if you could add some text like this plus some
> rationale (AIUI, this is geared mainly at new Atoms and other x86_64
> embedded platforms) to the document.
>
> (BTW, it is not really convincing to me that such a niche is worth all
> the trouble this is going to bring.)
It seems to me there's a much more general utility for this. After all,
the normal practice on 64-bit Power Architecture GNU/Linux systems, say,
is for most programs to be 32-bit and only a few that have a use for a
large address space to be 64-bit. For most programs, large pointers and
size_t are just a waste of memory (and so of cache) - but the extra
registers are significantly beneficial (as are such things as being able
to assume SSE to be supported). (Large files, 64-bit time_t, etc.,
however, are of wider use than large address space, but as I noted in
<http://gcc.gnu.org/ml/gcc/2010-12/msg00509.html> it would be a fairly
substantial project to address all such issues of inappropriate arbitrary
limits in C APIs.)
--
Joseph S. Myers
[email protected]
On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
> Hi,
>
> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
Really? I haven't seen this being posted for review yet ;-)
The basic concept looks entirely reasonable to me, but I'm
curious what drove the decision to start out with the x86_64
system calls instead of the generic ones.
Since tile was merged, we now have support for compat syscalls
in the generic syscall ABI. I would have assumed that it
was possible to just use those if you decide to do a new
ABI in the first place.
The other option that would have appeared natural to me is
to just use the existing 32 bit compat ABI with the few
necessary changes done based on the personality.
Arnd
On Sun, Feb 13, 2011 at 12:10 PM, Arnd Bergmann <[email protected]> wrote:
> On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
>> Hi,
>>
>> We made lots of progresses on x32 pABI:
>>
>> https://sites.google.com/site/x32abi/
>>
>> 1. Kernel interface with syscall is close to be finalized.
>
> Really? I haven't seen this being posted for review yet ;-)
>
> The basic concept looks entirely reasonable to me, but I'm
> curious what drove the decision to start out with the x86_64
> system calls instead of the generic ones.
>
> Since tile was merged, we now have support for compat syscalls
> in the generic syscall ABI. I would have assumed that it
> was possible to just use those if you decide to do a new
> ABI in the first place.
>
> The other option that would have appeared natural to me is
> to just use the existing 32 bit compat ABI with the few
> necessary changes done based on the personality.
>
If you are interested, please check out the x32 kernel to
take a look and provide feedback.
Thanks.
--
H.J.
On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>>
>>> 1. Kernel interface with syscall is close to be finalized.
>>
I don't think calling it "finalized" is accurate... it is more
accurately described as "prototyped".
>> Really? I haven't seen this being posted for review yet ;-)
>>
>> The basic concept looks entirely reasonable to me, but I'm
>> curious what drove the decision to start out with the x86_64
>> system calls instead of the generic ones.
>>
>> Since tile was merged, we now have support for compat syscalls
>> in the generic syscall ABI. I would have assumed that it
>> was possible to just use those if you decide to do a new
>> ABI in the first place.
>>
>> The other option that would have appeared natural to me is
>> to just use the existing 32 bit compat ABI with the few
>> necessary changes done based on the personality.
The actual idea is to use the i386 compat ABI for memory layout, but
with a 64-bit register convention. That means that system calls that
don't make references to memory structures can simply use the 64-bit
system calls, otherwise we're planning to reuse the i386 compat system
calls, but invoke them via the syscall instruction (which requires a new
system call table) and to pass 64-bit arguments in single registers.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sun, Feb 13, 2011 at 1:16 PM, H. Peter Anvin <[email protected]> wrote:
> On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>> The basic concept looks entirely reasonable to me, but I'm
>>> curious what drove the decision to start out with the x86_64
>>> system calls instead of the generic ones.
>>>
>>> Since tile was merged, we now have support for compat syscalls
>>> in the generic syscall ABI. I would have assumed that it
>>> was possible to just use those if you decide to do a new
>>> ABI in the first place.
>>>
>>> The other option that would have appeared natural to me is
>>> to just use the existing 32 bit compat ABI with the few
>>> necessary changes done based on the personality.
>
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. ?That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but invoke them via the syscall instruction (which requires a new
> system call table) and to pass 64-bit arguments in single registers.
>
That is is currently implemented on hjl/x32 branch.
I also added
__NR_sigaction
__NR_sigpending
__NR_sigprocmask
__NR_sigsuspend
to help the Bionic C library.
--
H.J.
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but invoke them via the syscall instruction (which requires a new
> system call table) and to pass 64-bit arguments in single registers.
Who actually needs this new extra API - whats the justification for
everyone having more crud dumping their kernels, more syscall paths
(which are one of the most security critical areas) and the like.
What are the benchmark numbers to justify this versus just using the
existing kernel interfaces ?
Alan
On 02/13/2011 01:28 PM, H.J. Lu wrote:
>
> That is is currently implemented on hjl/x32 branch.
>
> I also added
>
> __NR_sigaction
> __NR_sigpending
> __NR_sigprocmask
> __NR_sigsuspend
>
> to help the Bionic C library.
>
That seems a little redundant... even on the i386 front we want people
to use the rt_sig* system calls. As a porting aid I can see it, but we
should avoid deprecated system calls in the final version.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sun, Feb 13, 2011 at 2:03 PM, H. Peter Anvin <[email protected]> wrote:
> On 02/13/2011 01:28 PM, H.J. Lu wrote:
>>
>> That is is currently implemented on hjl/x32 branch.
>>
>> I also added
>>
>> __NR_sigaction
>> __NR_sigpending
>> __NR_sigprocmask
>> __NR_sigsuspend
>>
>> to help the Bionic C library.
>>
>
> That seems a little redundant... even on the i386 front we want people
> to use the rt_sig* system calls. ?As a porting aid I can see it, but we
> should avoid deprecated system calls in the final version.
>
That is the plan. I don't want to spend more time on fixing the
Bionic C library. Once x32 glibc is running, I will remove those
ia32 system calls.
--
H.J.
On 02/13/2011 01:16 PM, H. Peter Anvin wrote:
>
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but invoke them via the syscall instruction (which requires a new
> system call table) and to pass 64-bit arguments in single registers.
>
Oh, and as to why not copy the i386 system call list straight off... we
don't really want to add a new ABI with crap like sys_socketcall.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sunday 13 February 2011, H. Peter Anvin wrote:
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but invoke them via the syscall instruction (which requires a new
> system call table) and to pass 64-bit arguments in single registers.
As far as I know, any task can already call both the 32 and 64 bit syscall
entry points on x86. Is there anything you can't do just as well by
using a combination of the two methods, without introducing a third one?
Arnd
On 02/13/2011 02:28 PM, Arnd Bergmann wrote:
> On Sunday 13 February 2011, H. Peter Anvin wrote:
>> The actual idea is to use the i386 compat ABI for memory layout, but
>> with a 64-bit register convention. That means that system calls that
>> don't make references to memory structures can simply use the 64-bit
>> system calls, otherwise we're planning to reuse the i386 compat system
>> calls, but invoke them via the syscall instruction (which requires a new
>> system call table) and to pass 64-bit arguments in single registers.
>
> As far as I know, any task can already call both the 32 and 64 bit syscall
> entry points on x86. Is there anything you can't do just as well by
> using a combination of the two methods, without introducing a third one?
We prototyped using the int $0x80 system call entry point. However,
there are two disadvantages:
a. the int $0x80 instruction is much slower than syscall. An actual
i386 process can use the syscall instruction which is disambiguated
by the CPU based on mode, but an x32 process is in the same CPU mode
as a normal 64-bit process.
b. 64-bit arguments have to be split between two registers for the
i386 entry points, requiring user-space stubs.
All in all, the cost of an extra system call table is quite modest. The
cost of an entire different ABI layer (supporting a new memory layout)
would be enormous, a.k.a. "not worth it", which is why the memory layout
of kernel objects needs to be compatible with i386.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sunday 13 February 2011, H. Peter Anvin wrote:
> We prototyped using the int $0x80 system call entry point. However,
> there are two disadvantages:
>
> a. the int $0x80 instruction is much slower than syscall. An actual
> i386 process can use the syscall instruction which is disambiguated
> by the CPU based on mode, but an x32 process is in the same CPU mode
> as a normal 64-bit process.
Well, you could simply change entry.S to allow syscall with high numbers
to have the same effect as int $0x80, but not introduce another table
to solve this.
> b. 64-bit arguments have to be split between two registers for the
> i386 entry points, requiring user-space stubs.
64 bit arguments are very rare, and most of those syscalls are not
performance critical, so this could be dealt with on a case-by-case
basis, possibly by introducing a new syscall number for the variant
passing a 64 bit register.
> All in all, the cost of an extra system call table is quite modest.
The memory size overhead may be small, but auditing another table
for every change could become a noticable burden (your though, not mine).
> The cost of an entire different ABI layer (supporting a new memory layout)
> would be enormous, a.k.a. "not worth it", which is why the memory layout
> of kernel objects needs to be compatible with i386.
Right, this makes sense, you certainly can't redefine all the data
structures.
What would probably be a good idea is to compare the set of syscalls
in X32 and asm-generic, and to either eliminate or document the
differences. You can probably even take the asm-generic syscall numbers,
even if you keep the i386 data structures.
Arnd
On Sun, Feb 13, 2011 at 2:57 PM, Arnd Bergmann <[email protected]> wrote:
>
>> The cost of an entire different ABI layer (supporting a new memory layout)
>> would be enormous, a.k.a. "not worth it", which is why the memory layout
>> of kernel objects needs to be compatible with i386.
>
> Right, this makes sense, you certainly can't redefine all the data
> structures.
>
> What would probably be a good idea is to compare the set of syscalls
> in X32 and asm-generic, and to either eliminate or document the
> differences. You can probably even take the asm-generic syscall numbers,
> even if you keep the i386 data structures.
>
x32 system call number is BASE + 64bit system call number. It is
easy to keep 64bit and x32 in sync.
--
H.J.
> a. the int $0x80 instruction is much slower than syscall. An actual
> i386 process can use the syscall instruction which is disambiguated
> by the CPU based on mode, but an x32 process is in the same CPU mode
> as a normal 64-bit process.
So set a flag, whoopee
> b. 64-bit arguments have to be split between two registers for the
> i386 entry points, requiring user-space stubs.
Diddums. Given you've yet to explain why everyone desperately needs this
extra interface why do we care ?
> All in all, the cost of an extra system call table is quite modest.
And the cost of not doing it is a gloriously wonderful zero. Yo've still
not explained the justification or what large number of apps are going to
use it.
It's a simple question - why do we care, why do we want the overhead and
the hassle, what do users get in return ?
Alan
On Sun, Feb 13, 2011 at 3:39 PM, Alan Cox <[email protected]> wrote:
>> a. the int $0x80 instruction is much slower than syscall. ?An actual
>> ? ?i386 process can use the syscall instruction which is disambiguated
>> ? ?by the CPU based on mode, but an x32 process is in the same CPU mode
>> ? ?as a normal 64-bit process.
>
> So set a flag, whoopee
>
>> b. 64-bit arguments have to be split between two registers for the
>> ? ?i386 entry points, requiring user-space stubs.
>
> Diddums. Given you've yet to explain why everyone desperately needs this
> extra interface why do we care ?
>
>> All in all, the cost of an extra system call table is quite modest.
>
> And the cost of not doing it is a gloriously wonderful zero. Yo've still
> not explained the justification or what large number of apps are going to
> use it.
>
> It's a simple question - why do we care, why do we want the overhead and
> the hassle, what do users get in return ?
>
The real question is if we need to use ia32. If the answer is yes, then
x32 provides the benefit of ia32 with register extended to 64bit plus 8
more registers as well as IP relative address.
--
H.J.
On 02/13/2011 01:33 PM, Alan Cox wrote:
>
> Who actually needs this new extra API - whats the justification for
> everyone having more crud dumping their kernels, more syscall paths
> (which are one of the most security critical areas) and the like.
>
> What are the benchmark numbers to justify this versus just using the
> existing kernel interfaces ?
>
That's what the prototype is meant to show.
-hpa
On 02/13/2011 03:39 PM, Alan Cox wrote:
>> a. the int $0x80 instruction is much slower than syscall. An actual
>> i386 process can use the syscall instruction which is disambiguated
>> by the CPU based on mode, but an x32 process is in the same CPU mode
>> as a normal 64-bit process.
>
> So set a flag, whoopee
That's what we're doing, functionally.
>> b. 64-bit arguments have to be split between two registers for the
>> i386 entry points, requiring user-space stubs.
>
> Diddums. Given you've yet to explain why everyone desperately needs this
> extra interface why do we care ?
>
>> All in all, the cost of an extra system call table is quite modest.
>
> And the cost of not doing it is a gloriously wonderful zero. Yo've still
> not explained the justification or what large number of apps are going to
> use it.
>
> It's a simple question - why do we care, why do we want the overhead and
> the hassle, what do users get in return ?
The target applications are an embedded (closed or mostly closed)
environment, and the question is if the performance gain is worth it.
It is an open question at this stage and we'll see what the numbers look
like and, if it turns out to be worthwhile, what exactly the final
implementation will look like.
-hpa