Zack's Kernel News

Hardware Compatibility

Adam Osuchowski was poking around in the deep dark places of the kernel and came upon some hard-coded assembly that used the xadd instruction. Because the 386 CPU didn't implement an xadd instruction, Adam asked whether Linux still supported the 386. The xadd instruction turned out to be just a bug, but the incident sparked a discussion about which older systems were and were not supported under Linux.

In terms of systems supporting Symmetric Multi-Processing (SMP), Alan Cox remarked that the first system to support Intel's MP standard was the 486 with external APIC; he reckoned those would be the oldest systems capable of running SMP Linux, although he thought the Earth might have been denuded of such systems long ago. Maciej W. Rozycki commented, "I failed to track down a single 486 SMP system that would adhere to the MP spec. There were and possibly still are APIC-based 486 SMP systems out there, but most likely they are not Intel MPS-compliant, by not providing the MP header at the very least. Thus Linux would have to be ported and I gather the interest in doing so is epsilon. Myself, I could not resist trying an APIC-based 486 SMP box and possibly fixing issues if I found one and it was MPS-compliant, but nothing beyond that I would say. Life's too short."

In terms of the 386, various people speculated but no one could say for sure whether Linux would run on them. Jan-Benedict Glaw said he had an old, still-functioning 386 that he'd dug out of storage, and that, "… it still powers on and boots up that ancient Debian version. Using a 20GB (right, gigabytes) HDD." He said he might try experimenting with more current kernels and see whether they worked. Various other folks pointed out that 386 CPUs were still used in various embedded systems, and Ingo Molnar remarked that he knew of someone who occasionally booted up a 386 with current kernels. So apparently the 386 is still kicking.

Further Networking Security

Michael Stone proposed implementing a kernel feature to allow a process to irrevocably give up the ability to perform unrestricted network I/O, not just for itself but for all its future child-processes and their descendants. He said this would let users protect themselves from a whole big batch of evil software. Andi Kleen replied that this could be partially done, at least with outgoing packets, using netfilter. Michael didn't like this idea, though, and clarified a number of issues surrounding what he wanted this thing to do – the main points being that it should be process-centric and easy for distributions and vendors to adopt. He and Andi went back and forth on the technical merits of netfilter's ability to support these requirements, but at one point Alan Cox pointed out that there were ways for a process to break out of any such restrictions and that, really, more fine-grained security solutions like SELinux were the way to go.

Tux3 Compatibility Status

Daniel Phillips announced that Tux3 was abandoning compatibility with older kernels, and going forward it will compile only on kernels newer than 2.6.28. Tux3 would, however, continue to track the current version of the Linux kernel git repository. Tux3's own development continues to take place using Mercurial (, a version control system that came out at about the same time as git, and seems to be the only free version control system able to compete with git in terms of speed and distributed development features.

Getting back to Tux3, Daniel has announced that he is about to embark on implementing atomic commits, and so the code will be in a period of instability while that happens.

In any event, Tux3 is very much a development project, and should only be used by people who really enjoy testing filesystems.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More