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:

[Electrum]

If you swap ethernet cards, then it will exist when you boot the kernel, and you can configure it to be loaded with the kernel, at boot time. Being a module doesn't mean it has to be loadable at run time.

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.

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?

[Anonymous Coward]

> * All journalling file systems merged (XFS, JFS, ext3, ReiserFS)

I'd have to say, "never".

Each of these was designed to solve a different subset of the journalling issues, and ReiserFS is aiming for a superset as well.

Why do away with three good ones just to have a single choice? Is reading up on the four of 'em and selecting the one best suited to your system's needs (..while leaving other users the ability to do the same...) such a HUGE chore?

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".

debian violating social contract

[matusa]

I quote the second day of the summary (which is now also up:

In the last part of the talk, Bdale whipped out his Debian T-shirt and raised the question: does Debian violate its Social Contract by shipping the Linux kernel? The issue, of course, is the inclusion of proprietary firmware in a number of device drivers. Kernel developers, as a whole, seem unconcerned about proprietary firmware...

Ok, I'm a debian user/admin, I user it on all my machines, but this is just plain retarted. The kernel of your O.S. distribution violates your policies? Change your policies then.. or take the rod out of your ass.

it's funny how whenever you start to vehemently say 'for the people,' under weird beauracracy it can easily turn into 'we know what the people need better then they do' *sigh*

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...

[Anonymous Coward]

a) most support for execution of arbitrary objects is handled by the shell. a *lot* of things execute "/bin/sh *command*", which forks, calls the shell, then exec's the command based on what the shell determins should happen. this provided support for #!/path/to/interpreter style applications
b) that's already supported. all you need to know is the "magic number" that every .class file will have to make it identifyable, and you can use it.

go read the kernel config, under "General setup->Kernel support for misc binaries"
there's already docco on how to use javarse with that.

ashridah

Will we be forced to reboot?

[danlaba]

Rusty said about modules unitialization:

The third approach is simpler: simply deprecate module removal. It would remain as an optional feature (it is, after all, most useful for debugging kernel code), but, by default, module loading would be forever. In the end, says Rusty, kernel modules do not take that much space and memory is cheap; module removal may be an optimization that we no longer need. There are some residual issues, ... , but as a whole this option is easy and makes a lot of code go away. There seemed to be a lot of sympathy for this approach in the room."

Noooooo! Nooooooooo! Oh noooo!
This is why I have to reboot WinDOS, because they don't unitialize stuff, you have to reboot in order for new config to become active. They are not able to uninitialize actual config, initialize new config (remember, you had to reboot when you changed IP!!!)

It's easier, but.... whenever we update a kernel module we'll have to reboot.

Please don;t get rid of usefull code.

Thanks