Panel: The Linux Kernel – What's Next (Liveblog)
April 8, 2009 Leave a comment
Ted T’so – CTO Linux Foundation
Greg Kroah-Hartman – Novell
Andrew Morton – Google
Keith Packard – X.org
– now has a staging tree
– moving forward, focus will be on fixing what is already there.
– Intel stuff mostly “just works”. Lot of work going into ATi Radeon right now. nVidia is still not supporting native Linux efforts “at all”. Via is starting to engage the Linux community.
– each driver is a fairly concerted effort. There is a lot of silicon, complexity and logic in GPU’s these days.
– with most graphic stuff now in kernel, it’s easier to get started with small new experimental interesting projects.
– ext4 – 2 community distros will ship in the near future with ext4 enabled. Fedora 11 may make it the default.
– most recent bugs have not involved data loss.
– ext4 really represents a short term safe solution, but is based on old technology. Long term there will be a different answer.
– btrfs and nilfs are two of those.
– Are there too many filesystems?
* Linux Next
– comprised of over 100 branches
– has taken a lot of work out of doing -mm. He’d like to see it get more uptake, but think it’s still been a success overall.
* Is there a point where the Linux kernel community gets too big?
– the velocity of change remains astounding.
– there have been a lot of new “silos” and even subsystems that have popped up that have not been vetted by any of the old timers. This can cause issues.
* Audience question: There is a big push to get things in mainline, but often when someone actually tries to do that they run into a lot of opposition. How can this be improved?
– touch the kernel core as little as possible (systemtap was used as an example) and if you do, the code better be *very* good. If it’s a new driver or small subsystem, send it to Greg for Linux Next.
– utrace ran into the chicken and egg problem. Not enough users to get merged, but difficult to get users before you are in mainline.
– Knowing how to push a patch to the kernel community makes a big difference.
* Where do we stand with tracing?
– part of the problem will be evangelizing that tracers exist in the kernel.
– there is a large amount of interest in tracing now. A lot of what is going on now is experimentation and we’re still learning. Documentation is still poor, but they continue to get more usable.
* Audience question: What is being done to foster the next generation of kernel maintainers?
– Is actually something some of the current core maintainers think about. Being welcome, open and honest is a lot of it.
– The code is complex and growing rapidly. Just getting to know the memory system well could take 6-12 months. It’s a serious time commitment,
– what would a migration from iptables look like? A long process that would take 4+ years and would require serious vendor buyin. It has been done before.
– maintaining compatibility with the `iptables` command could help.
– in almost all cases, maintaining backward compatibility is a lot of work.
* A lot of new companies who never contributed to the Linux kernel are now doing so.
* There are now 1,200 contributors and the mix of sources is extremely varied.