Kernel Summit Wrapup

Jonathan Corbet at LWN has posted a terrific summary of the first Day of the Ottawa Kernel Summit, and you should expect the second day soon. In it he relates the greatest hits of the first day's talks, including the AMD Hammer Port, Block I/O, Modules, and more. For mp3s or oggs of this event, check out the Kernel Summit MP3 Repository on SourceForge. The big news is the desire to feature freeze 2.5 within 4 or 5 months. Halloween. I've posted a very small gallery of the group pictures from the summit on my site.

Comments

modules, and why Rusty is wrong:

[rodgerd]

Rusty started with the claim that the only purpose for modules was adding hardware that you didn't have when you booted your kernel.

Sorry, but this shows a paucity of imagination ("Rusty's smoking crack again"). Modules are useful because I don't have to rebuild the kernel constantly. I love not needing to care if I have to swap ethernet cards - tune /etc/modules.conf, reboot. Not "reconfigure and recompile kernel, fiddle with lilo, reboot".

I also love the fact that distros no longer resemble the bad old days where there where a billion different boot images for installation, depending on which combination of hardware I happen to have. Anyone want to guess the QA costs to RedHat if modules went away?

Rusty's wrong, wrong, wrong.

Re:modules, and why Rusty is wrong:

[ipfwadm]

"Your mouse has moved. Windows must be restarted for the changes to take effect. Reboot now? [OK]"

Watching karma fall through the floor for supporting Microsoft...

I have Windows 2000 on one of my systems, and this rebooting-after-everything is not nearly as much of a problem as it once was. Yes, after installing critical updates, the system does need to be rebooted, and some software still requests reboots on installation (which I typically ignore). But gone are the days where changing an IP address or other network settings would require a reboot. That's one of the big things Microsoft tried to do w/ W2K, cut down the number of trivial things that required reboots.

(Disclaimer: the system I'm typing this on is a Linux box that hasn't been rebooted in almost six months)

Re:modules, and why Rusty is wrong:

[rodgerd]

Broken binary compatability is considered by Linus to be a feature, not a bug. Essentially the kernel developers are unwilling to be constrained in their maniuplation of kernel internals by people who don't want to provide source.

The arguments around this have been hashed out time and time again on the l-k mailing list.

Re:modules, and why Rusty is wrong:

[infiniti99]

Well, y'see, there's this OS called Windows, made by this guy Gates... it might suit you better.

Somehow I knew I'd get a comment like that. I can't tell if you are a Windows user singing its praises, or some die-hard Linux user that wouldn't ever touch modprobe your life depended on it. Either way, your comment completely misses the point.

I find Linux to be a better OS in general, but it is not without flaws. What is the harm in fixing these flaws? I didn't say everyone needs to use a point-n-drool driver GUI. What I want is a better driver layer, so that stuff like that can exist if necessary. In the instance that you're a "die-hard Linux user", then continue to recompile your kernel or uncomment a modprobe line in your Slackware config whenever you want to install hardware. I just see a lot more potential with Linux driver configuration than that.

We ooh and ahh about "apt-get mozilla" or "emerge mozilla". Single commands that do all the hard work for you. Wouldn't it be great to have programs that could do the same kind of things for drivers also? The best part about Linux is that it is so flexible. You are not confined to a GUI or anything. A powerful underlying driver layer means more sane configuration, more powerful driver scripts, and the possibility of making easy-to-use configuration tools. And best of all, you can continue recompiling your kernel just as you may have always done. Yay! Everyone is happy.

My suggestion was to make Linux better, not to make it Windows. I hope you can see the difference.

Re:modules, and why Rusty is wrong:

[Ami Ganguli]

The reality right now is that the vast majority of drivers do provide source, so everything works pretty well. Requiring backwards binary compatibility for the modules interface would hurt everybody (because it creates cruft and a maintenance headache) and benefit only a few short-sighted companies

Remember that the general attitude towards binary-only modules is "we'll tolerate it, but if it breaks you keep both pieces". Nobody is demanding source, they just want to minimize the damage of closed-source code in the kernel. There's no reason everybody should suffer because of a few companies.

Re:modules, and why Rusty is wrong:

[Jeppe Salvesen]

Dude. If I had to compile in support for all possible hardware devices, my kernel would make xp look light.

Kernel modules are very cost-efficient things when you run a company. Rather than recompiling (or using a bloat-kernel), you can mostly run the same kernel on multiple computers from different vendors.

So much for "later in 2.5"

[iabervon]

Considering the number of things that are supposed to go in, including things that aren't really even started (beyond looking a bit at the issues) and things that are likely to be disruptive that haven't started to be merged, Halloween seems rather unrealistic. Of course, pushing off things that haven't been acceptably merged by then until 2.7 would probably make for the reduced-feature 2.6 that nobody wanted to commit to explicitly.

Personally, I like the idea of a 2.6 as soon as the big things which are partially merged are finished, with everything else put off until 2.7 and everyone who got their stuff into 2.6 responsible for making sure it's stable under wide testing. There are a number of big improvements already in 2.5, and cutting over to a stable release with those features would be nice. And maybe Marcello could be swindled into maintaining it because it's not _that_ different from 2.4...

Day Two Summary is available

[boa13]

I just saw the link on... Slashdot. Gee, these little side boxes are helpful sometimes. ;)

What's new in 2.5?

[RelliK]

What I especially want to see:

* ACLs!
* All journalling file systems merged (XFS, JFS, ext3, ReiserFS)
* No more VM stability issues

Anyone know if we can expect that?

On a side note, what are the four FSs above best suited for? I know ReiserFS is really good at working with lots of small files and XFS is excellent at data streaming. Anyone care to add more details?

Re:What's new in 2.5?

[MrResistor]

Mmmmmm..... ACLs......

There is a patch (or group of them) that give Linux ACL support. I don't remember the name of it, something like grsecurity. It was mentioned in the WOLKs interview a few stories before this one.

Re:What's new in 2.5?

[BJH]

I think "All journalling file systems merged" was intended to mean "All four file systems integrated into the kernel", not "all four fiel systems merged into one".

PC110

[BJH]

For those of you who might be wondering, the small PC that Alan Cox is shown as using in the photo is an IBM PC110.
It's a full x86 PC, not a PocketPC or PDA - and what's really amazing is it was put on the market in 1995.
I own three of the things... in 2000, the last stocks were sold for ridiculously low prices (compared to the price when it was originally sold, anyway), and I happened to have some cash in my pocket. At least they're small enough to not annoy my wife ;)
Anybody wanting to buy one should be able to find one on ebay fairly cheaply.

kernel developers to Debian: put up or shut up

[fw3]

my own favorite quotes from the discussion: - audio (approximately)

(Linus speaking): moving this (binary drivers with which Stallman / deb take issue) into user space is a sign of mental disorder .... we are clear from a copyright standpoint ... linux has intentionally taken a non-rabid standpoint ... as I've shown with my use of bitkeeper I don't care about black and white people.

[issues about firmware && binary modules]

(Alan Cox?) The kernel developers do not have energy to sit down and determine a clear set of rules ... Debian has an endless supply of people who have nothing better to do than study legal issues....

[Linus points out that actual GPL violating files get addressed in ca 24 hr timeframe]

The conclusion was to send a message back to the Debian users to "put up or shut up"

I'm sure RMS will have a press release out later this week.

Re:Ok, but...

[dvdeug]

When will the ability to run a .class file from a command line be part of the kernel?

Since at least version 2.2. See BINFMT_JAVA (obsolete) and BINFMT_MISC when compiling your kernel.