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

Re:Ottawa Linux Summit

[chrisd]

Uh, lets see, it is in Ottawa, and it is the Kernel Summit. Ottawa linux symposium starts tomorrow, fyi...

chrisd

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:

[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]

It works that way in DeadRat (kudzu). But that's a function of the userland, not the kernel.

Re:modules, and why Rusty is wrong:

[rodgerd]

Unless you have hot-swap PCI, hot-swap SCSI, USB, Firewire, PCMCIA/Cardbus devices, CF, or any of the other devices that don't require reboots to change.

Re:modules, and why Rusty is wrong:

[infiniti99]

Depending on the distribution (like, say, Redhat), that may be all you need to do in Linux also. However, I think the underlying system could be a lot better.

I have a mental list of about 5 things Linux needs to be really damn good. Better module support is one of them. Granted, I'm not a driver author, and I really haven't done much with compiling drivers since 2.2, so anyone please correct me if some of this stuff is already in place.

All drivers should be available as an add-on module. The idea here is to be able to load any driver when you need it, and to never have to recompile your kernel.

Binary compatibility between kernel versions. I mean, really, does it change _that_ much? I should be able to load a 2.4.0 driver on a 2.4.1 system. Why should VMWare need to have a bazillion drivers for various kernel versions? Maybe this is too late for older kernels, but how about considering backwards compatibility from this point on? Is it too much to ask that Linux 2.6 drivers should work in 2.8?

A very good interface for which modules can be interacted with (outside of the kernel). Currently there is insmod, which is able to specify additional parameters to a module via command line arguments. But what about errors? Are those returned as an insmod exit code or a standard text format? What about interacting with a module after it is already loaded? Is there a standard for probing whether or not hardware exists, other than simply seeing if the driver fails to load?
The end result is that I should be able to get a diskette from a hardware vendor that contains a nice driver.o file that I can load. If it comes with a driver.c file, then that's great, but I want a .o that I can just use right away.

Having a standard for probing and manipulating drivers is badly needed, so that someone can come along and make a decent Linux driver GUI. Yes, I know about Kudzu and Yast2, but something tells me they are doing a LOT of workarounds and/or "evil hacks" behind the scenes.

Solve this and we are well on our way to making Linux the best it can be. I really hope it is being addressed in 2.5

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:

[Anonymous Coward]

The end result is that I should be able to get a diskette from a hardware vendor that contains a nice driver.o file that I can load. If it comes with a driver.c file, then that's great, but I want a .o that I can just use right away.

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

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:

[Verizon Guy]

Neither does a binary one. Point is that whether something is open source or not, there should be a solution.

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:

[zenyu]

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.

While changing configuration options rarely requires a reboot in 2000, I do find it much easier to install Windows things in WINE than Windows proper. I installed .NET on a work PC and I swear it took more than a dozen reboots and a few hours of rebooting. Later that day I installed all the plugins for crossover and it took less than 20 minutes because the "reboots" were all instantanious.

Not that it would ever happen, but it would be a lifesaver if Microsoft just cleaned up the WINE code and switched to the Linux kernel for Windows YP. Though maybe that Lindows dispute went deeper than we thought. ;)

PS I used try to ignore the reboot prompt whenever I could, but it's resulted in a few burns. I hate reinstalling Windows so I follow it more religiously now.

Re:modules, and why Rusty is wrong:

[vrt3]

But gone are the days where changing an IP address or other network settings would require a reboot.

I agree Windows 2000 is a lot better in this regard compared to Windows NT or Windows 98, but you still have to reboot when you change the computer name!
I have no idea why, because if you use DHCP to retrieve the computer name you don't have to reboot when the DHCP-server changes the name.

Re:modules, and why Rusty is wrong:

[labradore]

Linux is not windows.

Linux is not windows.

Got it? When you use kernel 2.4.x instead of 2.2.x, most of the drivers for the hardware you use are available. If you have hardware that worked in 2.2 that does not work in 2.4 due to a driver that was not updated (incredibly rare) then you can get the source and update it yourself. There is a reason for this. The reason is that you are getting the system for FREE and the source for FREE. If you are using Red Hat or SuSE or Mandrake or Debian and your device is not supported in the new release then complain to them. Don't complain to the kernel people. Their mission is to make a good kernel, not to make it easy for you.

By the way, have you noticed that Windows 98 drivers don't work in W2K or XP? Have you noticed that many W2K CDRW drivers do not work in XP? Even Microsoft understands the virtue of changing binary compatibility.

It turns out that binary compatability is a really bad thing in the case of Linux. Here are some things that have come up at the kernel summit that would make guaranteed binary compatability prohibitively onerous: Async IO, loadable security modules and the coming SCSI changes. Got an old scsi card? Maybe you are running 2.2 or 2.4 right now and will switch to 2.6 when it's released. Async IO looks like it is going to become the normal way for Linux to handle IO. Your 2.2 or 2.4 scsi driver doesn't know about that. LSM also needs hooks in every part of the kernel to work efficiently, your 2.2 scsi dirver doesn't know about that (although it probably doesn't need to), the scsi stuff that is being pushed into the block layer code is probably going to make a pretty big difference for how your scsi driver interfaces with the mid and high level kernel scsi stuff. Binary compatablity for this sort of thing would be a waste of time for the kernel deveopers. The source and the interface specs are out there. It is faster, and more efficient all around to just fix older drivers than to make the clueless end user's life a tiny bit easier.

The right way to make life easier is the current way most modular drivers are able to be built now days. You can have a directory seperate from the kernel source tree that will contain your module criver code and you can tell it to build against your current configuration of the kernel in the source tree directory. This way you don't have to rebuild the whole kernel. You can either download the newest module source, or hack it up yourself and then build or rebuild it as many times as you need to if your module isn't supported in the official stock kernel sources. Binary only modules are just dumb and the vendor will have to be the one to make those modules compatible.

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.

Re:modules, and why Rusty is wrong:

[Electrum]

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

You're missing the point entirely, as did the original poster. The modules don't have to be part of the kernel. You can have modules that only get to be loaded at boot time. This solves the problem of having to being to be loaded and unloaded at run time, and all the various problems that go along with it.

I don't think anyone wants to get rid of modules entirely and put everything into the kernel. They want to eliminate run time loadable and unloadable modules.

Hot swappable hardware is different, as it's designed to be hot swappable. The individual devices can be hot swapped, but the base hardware cannot. You would need to load the module for a USB controller at boot time. The USB devices that use it would be controlled through this driver, and wouldn't need to be part of the kernel.

Re:modules, and why Rusty is wrong:

[darkonc]

It's also for software you didn't have when you booted the kernel (i.e. testing). If you had to reboot your system everytime you made a slight change to your module, it would increase the development time. I also don't think that there's that much difference between a boot-time loaded module system and a run-time loaded module (some, but not that much).

I think the better question is: what is the problem that rusty sees with run-time loadable kernel modules? I'm betting that they save most driver developers more than they cost.

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?

[Corby911]

Well, I know ext3 is great for ease of upgrade and backward compatibility with ext2. You can convert the root filesystem to ext3 without remounting read-only. Also, any ext3 filesystem can be mounted as ext2.

IIRC, it's also more "middle of the road" that reiserfs. What I mean by this is that (performance-wise), it supposedly eliminates the extreme cases. So, you get sligly worse handling of many small files, but eliminate some of the possible ultra-slow cases when dealing with large files.

Re:What's new in 2.5?

[groomed]

My experiences with XFS have been good. I've seen XFS shut down filesystems upon encountering I/O errors, so at least it tries not to be blithely destroy your data. There is a sense of maturity and the bag of userland tools adds to this.

XFS is quick when working with large files. I do a lot of audio work and the difference with ext2 is very noticeable. Since I haven't used ReiserFS I cannot make a comparison between XFS and it, but XFS is a big improvement over ext2, especially on large drives.

Other XFS features (although I can't say how well they work since I haven't tested them) include ACLs and the possibility to reserve a partition for "realtime" use, i.e. to provide a guaranteed minimum data rate.

The biggest XFS drawback as far as I can see is that it is not a standard part of the kernel. Whenever a new kernel appears you need to wait for a patch against that kernel version and apply it. This can lead to conflicts if you track multiple patches.

For most uses I imagine any of the 4 mentioned filesystems would suffice. Having tried only XFS, I can say that it is a definite improvement over ext2 though.

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?

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

Re:What's new in 2.5?

[iabervon]

There's a lot of places where the four of them do the same thing in different ways. One of the ideas was to have the common journalling code be shared between the different filesystems, and to have the various changes that need to be made to the general filesystem and disk code to support the operations needed for journalling be done in one way, rather than with different modifications for the different filesystems.

Obviously, they're not all going to be exactly the same: they have different on-disk formats and different consistency constraints. But there's a lot of stuff which should work with any journalling filesystem with the same code that ought to be straightened out between the different filesystems.

Holy Mary Mother of God

[soulsteal]

http://images.dibona.com/pictures/showpic/index.sh tml?Kernel02/convs/6x4_dscn4027.jpg

You see that whole back row? The uber-dorks have matured!

Re:/proc

[the_real_tigga]

ok. sorry for replying. please don't kill me.

that said, I would like to karmawhore nonetheless, by enumerating several useful links:

better swearing: c/o MisterBlister
read this first
and should you want to know how sexy swearing can sound for /. trolls like you, this one, too.

to understand the /proc directory

• General Info
• The Linux Kernel API
• /proc in general
• just for network tuning

PS: Oh, yea, and please spare most of my family too, MisterKlistier!

Ok, but...

[SHEENmaster]

When will the ability to run a .class file from a command line be part of the kernel? That is what I care about.

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.

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.

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*

Re: menuconfig

[fferreres]

I'd have a better alternative. Why not make the vendor configure the drivers for your hardware and have the kernel people extend the menuconfig so that you can load a "drivers config set" without altering all other options that you chose?

Then, they hardware vendor could provide an util to autodetec what kernel version you are using and tada. You could even make a "Wizard" (hehe) that you mama could use.

That should take care. Of course, the unsolvable problem is not this one, but the cases where some companies don't want to provide the sources. It's not Linux fault.

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:kernel developers to Debian: put up or shut up

[KjetilK]

Well, freedom is still Linux number one selling point. Tru64 is better on number crunching and Solaris is still better for most server applications, and windoze is better on the desktop. If they don't realize this, I think they will become irrelevant.

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

Re:Will we be forced to reboot?

[Sircus]

Since as a general rule, you only get a new module when you get a new kernel (and you have to reboot anyway for a new kernel), this isn't that huge a problem.

Re:Will we be forced to reboot?

[tarsi210]

I, for one, am incredibly worried about this. I often switch ISA NICs on the fly, unplugging them while the machine is hot. Unloading modules is very handy. Or how about those devices I plug in for a bit and then unplug? I like to remove the modules to clean up memory after using them (Zip drives and the like). When my soundcard crashes I have to rmmod and modprobe it back in to clear it out.

Please don't take away my module unloading. Rusty, I don't give a fark how kernel 1337 joo are, to say "memory is cheap" and be a kernel hacker makes you sound like a complete, contradictory moron.

Re:Will we be forced to reboot?

[Sircus]

What about them? For a start, NVidia's decision to release their drivers only as binary certainly shouldn't affect the design of the kernel. But to carry on, how often do you actually update lm_sensors? I run it too, but since it reports the values for all sensors installed on my system, I can't really imagine a reason why I'd want to upgrade it.

What about bugs + features + seek and install

[oliverthered]

If the kernel had a good modukle system (which i believe 2.6 is going to have) then modules are also good for.

Installing an updated driver with less bugs, security holes.

Installing an updated driver with more features (e.g. they make NTFS WR+ not just R)

You can get binaries of modules(this is called a comprimise!)

And bet of all the if you plug in a USB device etc.. and you don't have a driver, a daemon could go an find it on the net and download/install it for you!

Re:I would like to see bsd style networking

[Zaffle]

if any of you tried ip-chains or played around with NAT both under Linux then you know what I am talking about. Routing sucks bigtime compared to other unixes. I would like to setup NAT for 2 way address translation and a more readable scripts like ipf under *bsd but linux doesn't support it.

Its called iptables. Its in 2.4. Its good, and its very much comparable to *BSD style routing. iptables seems to be a pretty good solution. (Hey, third time's a charm. ipfw, ipchains, iptables, yey!).

As for the readable scripts. I tend to setup a script which just runs iptables how I want it. I use comments to state what I'm doing. Its very readable, and maintainable. If I want to see why a certain packet isn't going through, I open the script and look at what the comments say.

Re:retraction ~ Re:bloated ogg encoding

[chrisd]

The oggs are on average twice as long as what I consider a similar quality of mp3. They also took me twice as long to encocde.

chrisd

Re:Linux - lack of diversity?

[Nater]

See, the problem with making a statement like that is that now we all know that Race makes a big difference to you. Those of us who have actually reached a higher plane of existence and learned to ignore peoples' race wouldn't even notice that there were Asians and Indians, let alone that there weren't any Africans

Re:Linux - lack of diversity?

[Nater]

Hello. You seem to have missed the point. You're still looking at people's skin color and the shape of their face. Stop it, you're embarassing yourself.

If there are any people in this world who aren't contributing to Free software due to the dearth of developers of the same race contributing to Free software, then they are afflicted with the same problem as you, that is, the inability to ignore race.

There are two reasons why race is still an issue. 1) There are still some overt racists, and 2) there are people like you who are covertly racist. We're all just people, dude. Get the fuck over it.

tmtowtdi

[fw3]

The perl motto (there's more than one way to do it) applies to computing generally, and to the idea of what's the 'selling point'.

As it happens I have a couple of posts today about the what goes on in the OS market, so I'll just link Exchange on nt 3.1? & lessons for OSS and (long) Is Linux Dead. And yes, the market will hand irrelevancy to systems which don't adapt. If GPL does not adapt it will follow the same path, and by my read it has:

Beyond all that, free is not just GPL. FSF used to distribute X11 from the X-Consortium at ~$150 / tape Sometime later RMS decided the X11 license was 'bad'. Today, (perhaps with Debian/Hurd as his ace in the hole?) RMS is trying to push Linux to a strict (activist?) interpretation of GPL.

When I look a the history I think Stallman for all his principles exhibits pragmatism in his actions which is so often attributed to Linus. Linus made it clear long ago that he was not going to give FSF/Deb the blank cheque that many GPL developers do licensing under "gpl-current or whatever later version"

I daresay Linus drew a line in the sand saying "2.0 and no later version of GPL", and I bet if he hadn't we'd be looking at GPL-V3 today.

To be clear I'm not trying to knock either approach. I happen to have a bit more sympathy for Linus's views but that doesn't invalidate the strengths and accrued benefits of other approaches.