1 2 next »

1. x32 ABI and development status
2. In Brief and LKML

Kernel Log: x32 ABI gets around 64-bit drawbacks

by Thorsten Leemhuis

"x32 ABI" promises to take advantage of the benefits of 64-bit x86 processors without suffering from the overhead in 64-bit operation. At present, maintenance at Kernel.org has slowed down kernel development. Some kernel hackers are demonstrating their sense of humour with a Linux logo reminiscent of Windows 3.1 and a rickrolling kernel module.

On the LKML (Linux Kernel Mailing List), Intel developers H. Peter Anvin and H.J. started a discussion about system call numbers for an x32 ABI (Application Binary Interface). A program compiled for this ABI runs in the 64-bit mode of x86-64/x64 processors but only uses 32-bit pointers and data fields. This approach promises to get around the overhead that the 64-bit mode normally entails because a lot of commonly used applications do not need any 64-bit pointers and data fields. An x32-ABI could then use only 4 GB of RAM but still address the entire x86-64/x64 registry and such technologies as the SYSCALL64 interface, which are not available in the 32-bit compatibility mode that x86-64/x64 distributors currently use to execute x86-32/x86 applications.

The x32-ABI thus promises to take advantage of the benefits of x86-64/x64 processors while getting around some of the drawbacks of 64-bit operation. Applications would then run more smoothly, as the x32 ABI homepage explains. But there is only a handful of measurement data, and GCC support for the x32 ABI does not yet use some optimisation options, which makes it hard to compare the results.

Linus Torvalds was, however, not satisfied with some aspects of kernel support in x32; for details, see the LWN.net article "The x32 system call ABI". Fortunately, solutions seem to be on the horizon for a few of the problems discussed there.

The x32 ABI homepage talks about a number of packages that add support for the new ABI to the current Fedora, but these packages are not reachable at the moment because of maintenance at kernel.org. Time will tell whether common Linux distributions for x86-64/x64 systems will natively support the x32 ABI. The main people interested in this mode will probably be X86-embedded developers as x86-64/x64 kernels are increasingly becoming interesting for them for the simple purpose of addressing more than 4 GB of RAM. At the same time, they want to avoid the 64-bit overhead if possible because x86-embedded CPUs are not as powerful as the CPUs in the current desktop PCs and notebooks.

Development status

At the end of August, Greg Kroah-Hartman released the stable and long-term kernels 3.0.4, 2.6.33.19 and 2.6.32.46 as expected. In the release email for 33 series kernel, he emphasised that this kernel series is mainly being maintained for developers of the RT branch. The real-time kernel is currently based on 2.6.33 but will switch to Linux 3.0 soon; Kroah-Hartman has indicated that maintenance of the 33 series will then be discontinued.

Linus Torvalds broke the recent trend and did not publish a new release candidate of the next kernel version for the main developer branch over Sunday night and Monday morning; late Monday night, he did tag an RC6 but didn't announce it. Overall, kernel development has slowed down a bit since the break-in at Kernel.org. Initially, the servers were still providing the data they stored, but since the middle of last week kernel.org has displayed only a notice that it is currently under maintenance. Information stored at kernel.org, such as the error database, wikis, and other things, are therefore no longer reachable, which has hampered development. To make matters worse, there has been trouble with the DNS, leading to problems for a number of mailing lists, such as LKML.

Emails at LKML show that Torvalds is now also focusing more on where he will get the changes that he puts into the main development branch. In this context, he also confirms that he wants to rethink current work procedures in light of the break-in at Kernel.org. He emphasises that he places great store on personal relations, often even more than on technical solutions. In a few tongue-in-cheek remarks in the release email for Linux 3.1-rc5, Torvalds tried to make it clear that users should not trust every source that offers Linux source code and patches.

Next: In Brief and LKML

1 2 next »