lca2008 — state of the fedora kernel miniconf

Presented by Dave Jones, another good talk. Some notes:

  • Fedora is going to start providing a vanilla upstream kernel in their yum repos to make reproducing bugs easier. This solves the problem of, “oh, you saw a problem in fedora? does it reproduce upstream?” Any distro that maintains custom patches should implement this solution.
  • Fedora 9 is tentatively aimed for May release, which is approximately the 2.6.25 timeframe. Woo!
  • One of the most anticipated features for F9 will be the stabilization of the on-disk format for ext4. This is a big deal for early adopters, since it would really suck if they started using ext4 and all of a sudden the format changes. Oops!
  • Starting to change thinking about drivers that are not yet accepted upstream. Fedora is going to start shipping them because “a crappy driver is better than no driver”. Doesn’t mean it’s a free-for-all — there are still baseline requirements, like there needs to be an active maintainer, etc. Still, this is a good sign for the users.
  • Xen continues to be a headache. (Does anyone like xen?) Parts of Xen have finally been accepted upstream (after 3 years), but what’s currently shipping in F8 today is actually more featureful than what’s upstream, as the Fedora guys maintain their own bunch of backports and patches. This is the case for almost every distro, I think. There might be a nice way out of it — running a xen domu on top of kvm. Clever and clean, in my opinion.
  • gonna start supporting kernel mode setting. This provides a way for the kernel to change / modify the graphics display (yes, X will need to change to support this). Why would you want this? In case you get a kernel panic while in X — instead of just seeing your screen lock up without reason, the kernel can now dump panic info to your graphical console. Booya.
  • better kgdb / kdump integration. akpm is already carrying kgdb patches in -mm, davej wants to see these merged. Anything that makes debugging easier is good. kdump is pretty cool and shipping in F8 today (modulo whatever setup that needs to happen). The scripts could use some improvement, and my impression was that there’s going to be something better for F9.
  • RHEL6 may or may not be based on F9. Seems like internally, they’re treating it as if it were to be so, which is a pretty good hedge. At worst, all it means is that F9 will be really good. Still, there’s a chance it’ll be based on F10, but in any case, pretending that F9 is the new base of RHEL6 would seem a prudent course of action.
  • Big problem is gathering enough debug information. One of the problems is that Fedora adds the “quiet” argument to the kernel cmdline, so users can’t tell where their kernel might hang. Educating them on how to modify /etc/grub/menu.lst and turn that off, etc. etc. is hard. Yours truly suggested providing a “debug mode” (similar to safe mode) which turns quiet off and boots a debug kernel as a grub menu option, but davej said that the Fedora grub guys are pretty resistant to adding new options (don’t want to confuse the users). They’ve got a point, but there must be a way to hide that sort of magic normally until a developer asks you to press the magic key combination. Someone else suggested just making safe mode do exactly that, which is a good idea too. Real time open source, brosephs!
  • Other bug related things — installing Arjan’s oops daemon to help get more info, setting up a netconsole, and perhaps something like bug-triage day. Good ideas, all.

Yowza, that was a lot.

Edit: hrm, better update this entry so people who did not come here via a link from Dave Jones’ LCA entryget the right ext4 information. Dave writes:

(The bit about ext4 is somewhat optimistic. There’s a ton of stuff left to do for ext4 before it loses its ext4dev moniker. I possibly misled people into believing we’re shipping this in F9 regardless of it state due to the pending changes for .25 The reality is that until the ‘dev’ goes away, I’m paranoid about more last minute on-disk format changes.)