« previous 1 2 3 4 5 6 7 next »

Massively restructured

In 2.6.24, Linux developers unified the source code for the two x86 architectures previously kept in separate directories in the arch/x86/ directory (see this commit, for example). The two architectures each used to have their own directories, although considerable parts of the code base of the 32-bit x86 architecture known as x86, x86-32, i386, ix86 or IA32 and the extended 64-bit command set known as x86-64, x86_64, x64, AMD64T, EM64T or IA32e are actually similar or identical. In the past, this occasionally caused corrections only to be integrated, for example, in the x86-32 code at arch/i386/ while arch/x86_64/ was left untouched - or the other way round.

Specially programmed scripts simply merged the files which are identical for both architectures; code which only applies to x86-32 systems was moved to files tagged with _32, while file names for specific 64-bit code contain a _64 tag. Include and makefile tricks can then be used, for example, to prevent code for old x86-32 systems from being incorporated in x86-64 kernels. Developers plan to tidy up the details and, where applicable, merge _32 and _64 files in the next few weeks.

Wit these substantial restructuring measures, developers hope to achieve simpler source code maintenance and in the long term a more reliable kernel with fewer flaws. Merging the files also reduces the effort needed for porting newly developed x86 technologies. Apart from these indirect advantages, there are no noteworthy effects for users; however, those who compile their own kernels now have to adjust their configuration and choose between a 32-bit or a 64-bit kernel. Scripts which may expect to find the compiled kernel, for example, at arch/{i386,x86_64}/boot/bzImage, also need to be adjusted.

Discussion about the plan to unify had started last July - and many developers were very keen on the idea from the start. However, some hackers were also opposed to the idea - for example Andi Kleen, then code administrator for x86-32 and x86-64 architectures. However, Linus Torvalds and other leading developers prevailed and implemented the unification plan - resulting in the administrator for x86 architectures stepping down. This task is now jointly handled by Thomas Gleixner, Ingo Molnar and H. Peter Anvin.

Improved Infrastructure

While the x86-32 and x86-64 directory unification only caused a few bug reports during the development of 2.6.24, kernel hackers were less fortunate when restructuring the driver API for DMA-I/O operations: Some architectures displayed operational flaws with various drivers. Although the developers quickly fixed the flaws, some of the drivers are maintained independently of the kernel and may also require updating - usually, driver administrators only begin the update process once a new Linux version has officially been released.

Following a long development period, a series of "anti-fragmentation" patches was finally integrated in 2.6.24 which are to limit memory fragmentation - hardly any larger unfragmented memory areas were previously left after a few days of intensive use.

LSMs (Linux Security Modules) can no longer be unloaded; the external API for LSM-based code was removed in the same patch. These two changes are controversial and sparked a long discussion.

When waking up x86-64 systems (from suspend-to-disk/hibernate), any kernel can now be used to restore and execute the previously created memory image.

An update for the Ext4 file system fixes several bugs and offers two new features: "Uninitialized Block Groups" to speed up creating and checking file systems, and "Flexible Block Groups" for faster processing of large files in file systems with small block sizes. Ext4 will retain its experimental state for now.

Apart from all these changes there are numerous others which, depending on the field of application, are more or less relevant for Linux users. Find a list with short descriptions at the end of this article.

« previous 1 2 3 4 5 6 7 next »