Ask New 2.4 Maintainer Marcelo Tosatti Anything

Linus keeps hinting (declaring, even) that he's nearly ready to work full-time on the 2.5 development branch of his kernel, and hand the 2.4 kernel off to Marcelo Tosatti. Marcelo's graciously agreeed to answer questions (you might want to read some of his mailing list contributions first), so here's your chance to ask him what he'll do in the famous footsteps of Linus and Alan Cox, and how he got there. Please only put one question per post; we'll pass along the top-rated comments to Marcelo for his answers, and hear back from him shortly.

Re:Ask Marcelo Tosatti Anything?

[digitalsushi]

i think this is a valid question, if the answer is creative enough it will offer some insight as to his overall maintenence methods, albeit abstract (but we all deal with massive abstraction on the internet anyways, so why complain)

Re:Why you?

[Anonymous Coward]

What makes you think it's *your* kernel?

list of changes for the common folk

[e40]

One thing that is really missing is a list of changes in each kernel release that is meant to be consumed by the masses. The "changelogs" that are offered up are sorely lacking for us non-kernel hackers. What I'd like to see is a prose description of the changes in each version. Something like Release notes for 2.2.18 by Alan Cox [linux.org.uk] is a step in the right direction, but some of it is even a little too technical. For example, in the above document,

set_current_state

• Fixed potential SMP race

means little to me and probably a lot of other people. Under what condition does this occur? The question why should I care about this change? should be answered for each entry.

How do you feel about doing something like this?

Linux 2.4 future focus

[tercero]

Recently there was a post on /. that asked for a stable and fast kernel. (I'm too lazy to look it up.) The poster cited older kernels' stability and speed and the trend toward recent kernels having too many bugs to be worth all of the new features they have.

What will be your main focus while maintaining 2.4, stability or backported extra functionality. It is doubtless that there will be some backports. But what will you focus on stability and speed or features?

Re:Any plans to improve documenting the kernel?

[SW6]

Buddy system. Hairy. You really aren't expected to understand this.

Heh. This is very similar to the comment in the original Unix sources. The idea was that it was completely obscure until one understood something magical that couldn't be documented, at which point it didn't need commenting. A lot of really low-level stuff can be pretty obscure and mind-bending - it's just a fact of life when dealing with such things and documenting it doesn't help.

By the way, the Buddy System is a memory allocation strategy given by Donald Knuth in his book "Fundamental Algorithms". It's pretty obvious once you've seen how it works, but I'd have never thought of it independently. I would assume that understanding the code requires one to understand the algorithm first - e.g. by reading Knuth's excellent description that is unfortunately too long to stick in a comment.

Re:code control

[Erik Hensema]

Subquestion: if you'd put the kernel under CVS, would you allow commit access to key developers?