Robert Love, Preemptible Kernel Maintainer Interviewed

Tom F writes: "LinuxDevices did an interesting interview with Robert Love, the maintainer of the Linux preemptible kernel along with MontaVista. It is an exciting read and has Robert's usual wit and insight."

Comments

Kernel Maintainer

[Anonymous Coward]

I've got questions about kernel maintainers. When would you want to put someone on the job of maintaining a kernel version?

Obviously, you want someone that knows the kernel really well and can maintain every part of it.
BUT
Aren't you taking a good developer (who can maintain every part of the kernel) away from the newer versions of the kernel?
There are only so many developers, what happens if you run out?

Preemptive kernel looks good

[Marx_Mrvelous]

His comments on the preemptive kernel patch make me want to try it out. It seems like a great idea, and from what he says, it's well-implemented.

On a side note, he's my kind of geek. At least started with Slackware, kernel hakcs and even has a girlfriend. Wow!

Re:Preemptive kernel looks good

[Toraz Chryx]

*cough*AmigaOS*cough*

preemptive multitasking since 1985 :)

low-latency patch

[S. Allen]

I'd also like to see an interview with the author of the low-latency patch as well as a comparison of the two. Bits I've read from Kernel Traffic give me the impression that people think the low-latency patch generally provides better responsiveness and scalability.

Re:low-latency patch

[steveha]

I have been following these two patches a bit, because I want my desktop to be as snappy and responsive as possible.

The current low-latency patches work by finding "hot spots" in the kernel code where something is taking a long time, and then putting in a hack to make the code yield. The good part is that you can get a really low-latency kernel; the bad part is that you have to touch the kernel code in hundreds of places, and the kernel code gets really ugly. I remember reading that Ingo Molnar, who wrote a giant low-latency patch that worked this way, agreed with Linus that his low-latency patch was just too ugly and huge and should not be included in the main source tree.

The preemption patch is comparatively small and elegant. It leverages the work that has already been done to make SMP work correctly. I'm using it on my Linux desktops, and I like it.

On one of the mailing lists, Linus said that he wants the Linux kernel to gain low latency the cleanest way: find all parts that are slow, and instead of hacking them to yield, re-write them so they are faster (but still clean code that is easy to understand). This is of course the ideal, but when will it be finished? The preemption patch is available now, and works now, and I am using it now.

steveha

At the moment, yes

[Astral Traveller]

Right now it's just a patch. But Linus has made it clear that he is unwilling (for whatever foolish reasons) to accept Love's patches. If the preempt patches become popular enough (as they no doubt will amongst those using Linux for multimedia production), it won't be long before somebody decides to fork the kernel with preemptible patches simply to make it easier to use for more people. From there, you could very quickly end up with yet another completely different operating system kernel.

Re:Impressive.

[mattbelcher]

He goes to the University of Florida. As a recent grad (last May) with a degree in CS and Math (the same as what he's working on) I can tell you, if you need the time, its easy to find. I was busy, but only because I pushed myself - taking many more classes than I needed to. Hell, if you are intelligent and willing to accept C's, you probably don't even need to go to class or finish half the assignments.

As an aside, I'd love to see how he breezes through COP4600 (Operating Systems). Adding symbolic linking to Minix would be cake after the work he's done.

Nice buzzwords

[yusing]

I "grew up" in the 8-bit era and recall that we used vectored interrupts to handle real-time needs. That worked extremely well with processors running at 1/1000 of today's speeds.

After reading the article, I'm left wondering why "unpreemptable kernals" were ever conceived in the first case. To lower the cost of hardware? On the "limited-access freeway" model? Or just to K.I.S.S.?

Re:Nice buzzwords

[Anonymous Coward]

It was because Linus incorrectly thought Tanenbaum didn't know what he was talking about. (Everyone seems to have the impression that Linus "won" that debate. They are wrong.) So instead of writing a modern OS with a microkernel (where there isn't much to preempt) he went with the 1970s approach. We'll all be paying for that until the day we switch to HURD.

Re:Why do we need so many different kernels?

[Anonymous Coward]

It seems almost certain that, with Love's preemptible fork, Alan Cox's own fork which is steadily separating from Linus' core, and of course the "classic" Linux kernel, the Linux operating system will soon end up like *BSD, with several mutually incompatible, infighting factions. We can't let this happen.

As long as the API's are the same, and they maintain binary compatabilty for applications, what's the difference? Seems to me it would actually be a Good Thing. You could then choose the kernel/distro that optimizes performance for your particular choice of applications.

Pre-Emptable Kernel & MicroKernels

[sl3xd]

I'm ignorant of this fact... but it almost sounds to me like having a pre-emptible kernel is one of the 'featues' of a MicroKernel --

Although I'm fully aware of the fact Linux is NOT a MicroKernel, what significant differences exist between Pre-Emptible Linux and a MicroKernel Linux?

(Aside from the fact that all of the Linux kernel, drivers, etc. is in 'kernel' mode, and a MicroKernel has only the message-passing and task-scheduling in 'kernel' mode, and everything else (drivers, etc.) run in 'user' mode.)