Vanishing Features Of The 2.6 Kernel

chromatic writes "Jerry Cooperstein has written an excellent article summarizing the features removed from the upcoming 2.6 kernel. One controversial change may be tightening restrictions on binary-only modules." And Lovechild writes with some more 2.6 news: "I recently did an inteview with famous kernel hacker extraordinare and all round nice guy Robert M. Love for Tinyminds.org, about kernel 2.6 and what can be expected for desktop Linux users, when the new kernel series is released.

Comments

Binary modules

[IamTheRealMike]

Could somebody sum up the pros/cons of binary modules. I've been trying to understand this issue for some time, but it's nearly impossible to get technical reasons without ideological bias. So far I have:

Pros:

• Commercial interests are happy because they keep trade secrets they may need to stay in business
• Better drivers (usually)
• Patented tech can be used in Linux, like that nVidia texture compression thing (i don't think all patents are stupid).

Cons:

• Makes kernel harder to debug
• Sticky GPL enforcenment issues
• Some kernel developers don't like it
• Often come with stupid licensing, ie nVidia - you can't distribute our drivers, only download them (and then no psyche rpms).

Have the kernel devs decided whether they are good or not?

Re:Binary modules

[Otter]

Cons:

As a PowerPC Linux user, I'd add that they're rarely made available for non-x86 architectures.

Re:Binary modules

[bbk]

I've always heard it stated as a debugging issue - if a bunch of people send in bug reports saying "Kernel 2.x.x is broken", and they're using a binary only module, how do the linux developers know the problem is with the kernel, and not with the binary module? To aid in debugging, they put limits on what binary only drivers can do, which narrows the range of problems.

I think it makes a good deal of sense, from a linux developer standpoint - they all have their own reasons to work on linux, and answering bogus bug reports caused by faulty binary modules cuts time from other development tasks.

BBK

Re:Binary modules

[kasperd]

Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver

The mouse driver is one of the simplest drivers, and most of the stuff is done in usermode anyway. But a changing interface doesn't mean that each and every piece of the interface changes, it just means that the overall interface has changed in some way.

It doesn't take much to make a change in the binary interface, a small change of a .h file will do. In fact even changing just a kernel configuration option could change the binary interface. The API on source level is however more stable. It doesn't change that often, and it doesn't change in unpredictable ways by modifying something completely unrelated to what you are writing. This API has been kept almost unchanged all the way through the 2.4 series.

Re:Binary modules

[vinsci]

It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system. Imagine the screaming that would take place if they tried that.

Microsoft are busy working on just this and it's much worse than you would imagine. See the TCPA/Palladium FAQ.

Translations: German, Spanish, Italian, Dutch, Chinese, Norwegian, Swedish, Finnish, Hebrew and French

Just great...

[xchino]

I am an op in a Linux support channel on IRC, and I always dread new rleases of both kernels and redhat. It never fails.. some noobie comes in *demanding* we help him fix the production mail server he just trashed by installing RH8 or the newest kernel (dev or otherwise).

For anyone out there who is just waiting and drooling on themselves over 2.6, unless you NEED one of the few features present in a new kernel, you have no need to upgrade. The latest isn't always the greatest, and even "stable" releases need to go through testing before you put them in production.

Binary modules can still be used.

[cureless]

I've seen quite a few posts that seem to imply that binary modules cannot be used with the new kernel. That is not true.

What is true is that they are doing things like not exporting the system call table so that any module can change it at their will. That is, a binary module can't replace the write call or fork call. There are other mechanisms like syscall registering for modules that need some new system call. (I haven't looked into that aspect yet).

What they are doing is not encouraging binary only modules. (and by binary I mean non GPL). The example they use is the modification of work queues. Things like tainting the kernel (so the kernel knows when it's been tampered with by proprietary code (read loaded a non GPL module)) have been around for a while now. Kernel people will not give support to problems with tainted kernels.

I use and nvidia driver in one of my computers, and that taints my kernel. I understand the implications. I also see no reason why nvidia has to modify my syscall table.

In short, I don't think normal "drivers" need to modify the syscall table. You can add a new filesystem, network protocol, etc without the need to modify the syscall table. So stop complaining about no more binary only drivers.

I agree with the developers in the choice. I also wish nVidia, along with the other companies, GPLed their drivers. After all, they are _drivers_ for the hardware I bought. And if they don't want to, they could at least release the complete specifications for the hardware so we can build our own 3D accelerated drivers.

cl