KS2009: Generic architecture cleanup

Arnd Bergmann ran a quick session on improving the way architectures are supported in Linux. The usual way to add an architecture is to clone the x86 tree, then bash away on the code until it works on the new processor. That means that a lot of code has been duplicated over time, much of it uselessly. There is still compatibility code to help in the running of Xenix binaries - on architectures invented long after Xenix faded into obscurity. The end result is that it's harder than it needs to be to support new architectures; they all keep making the same mistakes.

So Arnd has been working with the newer architectures over the last year. He has created a new include/asm-generic hierarchy to contain headers which should be shared across architectures and has been porting architecture code to use them. In particular, he has focused on the relatively new MicroBlaze and S-Core architectures; this work has resulted in significant reductions in the size of the affected code.

There was lots of talk about grungy details that your editor did not record very well. One sticking point appears to be the TERMIOS ABI, which differs significantly between architectures.

What remains to be done? It would be nice to get glibc to use the generic ABI definitions whenever possible, but nobody seems to know how to get that support into the library. More architectures can be moved over to the generic code. Arnd talked about the creation of a skeleton architecture which can be used by future implementers; he was thinking about making something which would run under KVM. Other developers recommended using a real architecture in this role; MIPS was suggested as a good starting place.

Next: Development process issues

---

to post comments

Origin of asm-generic

Posted Oct 23, 2009 13:45 UTC (Fri) by arnd (subscriber, #8866) [Link]

Actually, the asm-generic headers have been around for ages, but what I
did was to add the half of them that was not already there, and to extend
some of the existing ones to make them usable without providing any
architecture specific information.

There also was an earlier article about a presentation I gave at the UKUUG
Linux conference last year on a related topic, see
http://lwn.net/Articles/307713/.