Zack's Kernel News

New Kernel Architecture

Michal Simek created a new Linux architecture to support the Microblaze CPU. He asked what the maintainership duties would be and whether he could get his own git repository on kernel.org to house the tree. Regarding the git repository, Jan Engelhardt suggested that a repository on kernel.org was not really necessary; instead, he suggested maintaining a separate repository, which also would give Michal more freedom to manage it however he pleased.

Stefan Richter agreed that, in terms of workflow, there is not much reason to choose a kernel.org-based repository over some other hosting solution, but there are some advantages to having the repository on kernel.org. For one thing, git objects could be shared with Linus Torvalds's official tree - as a number of kernel.org-based repositories already do - resulting in repositories that are a fraction of the size that they would otherwise be. Also, the different tree owners can fetch each others' trees locally on kernel.org without having to go over the Internet, which could save considerable time if Michal needs to do that regularly.

Various folks responded to Michal's maintainship query. People generally agreed that the duties were light, requiring as much time as Michal wanted to spend, but Pekka Enberg pointed out that it also would be better to keep the list of official maintainers short. Pekka suggested that if more people were going to maintain the port, it might be useful to compare the situation with other ports and possibly start a separate mailing list for the discussion between maintainers.

Stefan Richter suggested that patches would need at least some public review, either on a specialized mailing list or on the linux-kernel list. Bryan Wu pointed out that eventually the patches must go to the linux-kernel list for consideration. He added that Michal would need to pay attention to the responses he received about his patches and be prepared to develop revisions quickly; then, typically, his patches would go into Andrew Morton's -mm tree, where they would marinate until being passed up to Linus for final inclusion into the official tree.

Bryan and others also talked about the "merge window," Linus's current effort to produce timely releases. Bryan suggested sending patches to the mailing  list after the merge window opened, typically two weeks after the previous release. Pekka disagreed and said that waiting for the merge window only would delay the code's inclusion, and Stefan explained that the merge window only applied to code that had been reviewed thoroughly and tested. To reach that stage, Michal would have to submit his code as early as possible.

Arnd Bergman had some advice for Michal, especially about the initial merge into the Linus tree. Arnd suggested splitting all drivers into their own git changeset, and then splitting that into easily reviewed chunks that could be reviewed individually.

Linux 0.01 Lives!

Abdel Benamrouche ported the original Linux kernel version 0.01 to GCC version 4. In addition to being extremely cool, Cong Wang pointed out that this would be useful for teaching operating systems to Computer Science students. Cong also sent Abdel's work along to the professors in his Computer Science department.

Kernel Docs in Chinese

Greg Kroah-Hartman posted a number of patches on behalf of various kernel-documentation Chinese translators. Li Yang, Zhang Le, Bryan Wu, and others have contributed to translating Codingstyle, oops-tracing.txt, and other docs in the kernel source.

Setting Numlock from the BIOS

Bodo Eggert wrote a patch to read the default Numlock status from the BIOS data area on the IBM PC. This retro-cool technology goes back to 1981. Getting Numlock to default to "on" under Linux has been consistently difficult, requiring users to roll out their own solutions. Bodo's code promises to make this challenge easier to overcome.

Generalizing Script Dependencies

Andreas Mohr was unhappy to find shell scripts in the kernel source tree that relied on bash while still specifying !#/bin/sh in their code. On his system, for example, this meant that the default shell choked on the scripts because he used the dash shell instead of bash. Andreas decided to remove all the bashisms from at least the patch-kernel script, so he submitted a patch to do so. Everyone loves a good bashism discussion, so there were plenty of comments about his work and he submitted several revised patches for consideration. At one point, Adrian Bunk politely pointed out that a quicker solution might be to fix the top line of code, making it #!/bin/bash instead; however, no one was deterred by this effort at practicality.

Ext4 Fast Track

Despite being experimental, unreliable code, the ext4 project has been receiving preferential treatment and lived in the stable kernel tree for a while, in part because ext4 developers look awfully similar to the ext3 developers, who tend to be well known and trusted. Even so, the code is not ready for widespread use, yet it was attracting new users just by virtue of its presence in the main tree, which was intended to allow anyone to test it.

Adrian Bunk felt the situation was too dangerous, given his direct observations of users adopting the code simply because it was there. Bunk submitted a patch to make the filesystem dependent on BROKEN, which at least would provide an adequate warning.

Some people felt this was too extreme and that marking the code EXPERIMENTAL should be enough. This would allow users to select the code from the most commonly used interface instead of manually removing the dependency on BROKEN, which pointed back to another problem Adrian had been trying to solve - the over-dependence users had on features marked EXPERIMENTAL. Because so many necessary drivers rely on this, users tend to enable experimental features by default, allowing things like ext4 to creep into their configuration options as if they were ready to be used. Adrian has been trying to eradicate the EXPERIMENTAL kernel configuration option for months.

Other people objected because putting ext4 into the main kernel tree was meant to let people test it, but Adrian reminded folks that ext4 is a special case and it's unusual for the main kernel - at least in this phase of development - to have such an unstable feature.

There was quite a bit of opposition to Adrian's change, including Alan Cox asserting that getting rid of EXPERIMENTAL was wrong and an attempt to rewrite history. The discussion ended inconclusively, but it is clear that ext4 has some powerful advocates who want to encourage user experimentation as broadly as possible, and who don't want to go through the usual hoops that filesystems jump.

The situation is reminiscent of ReiserFS , which was attacked and barred from the kernel for not fixing all the issues the various kernel developers had with it. In fact, personality conflicts with Hans Reiser were perhaps more to blame for ReiserFS's exclusion from the kernel tree, but other filesystems have been expected to undergo similarly tough review. Because ext4 is being developed by kernel "insiders," it gets special status. How this special status will play out remains to be seen, as do any precedents it may set for future projects.