Quotes of the week [LWN.net]

May be I should start to stick posters with photos of modules entitled "I want to believe" everywhere in my flat. Or perhaps I'm going to buy electronic glasses that display modules advertizing in the street. I'm not sure yet but I'll find a way.

-- Frederic Weisbecker

I thought everyone learned the lesson behind SystemTap's failure (and to a certain degree this was behind Oprofile's failure as well): when it comes to tooling/instrumentation we dont want to concentrate on the fancy complex setups and abstract requirements drawn up by CIOs, as development isnt being done there. Concentrate on our developers today, and provide no-compromises usability to those who contribute stuff.

If we dont help make the simplest (and most common) use-case convenient then we are failing on a fundamental level.

-- Ingo Molnar

Jan suggests that we not surprise users by having delalloc enabled when ext3 is mounted with the ext4 driver. However there are other behavior differences as well, mballoc behavior comes to mind at least. What about the 32000 subdir limit? If we go back to ext3 is it ok with the subsecond timestamps and creation time etc? Maybe so... have we tested any of this?

At what point do we include the phase of the moon as worth considering when describing ext4.ko behavior?

-- Eric Sandeen

to post comments

Quotes of the week

Posted Mar 18, 2010 19:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

"perf is mainly a kernel developer tool, and kernel developers generally dont use GUIs to do their stuff: which is the (sole) reason why its first ~850 commits of tools/perf/ were done without a GUI. We go where our developers are."

So it's now _really_ official. Kernel developers really hate userspace developers and administrators. That's why they don't want SystemTap.

Quotes of the week

Posted Mar 18, 2010 19:40 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

Err, perf is a userspace tool. This is a discussion about how some kernel
developers want to see userspace development happen when it is tightly
associated with the kernel.

Quotes of the week

Posted Mar 19, 2010 22:49 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

And now Ingo wants *qemu* in the kernel development tree. Madness. (How
many non-Linux-x86 arches does qemu run on, again? How many CPUs can it
simulate?)

Quotes of the week

Posted Mar 19, 2010 23:00 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Actually what he wants is a minimal version of qemu that fits KVM needs in
the same space as perf. You can read the the different threads in detail for
the discussions. There are many valid points for this sort of model of
development.

Quotes of the week

Posted Mar 20, 2010 1:51 UTC (Sat) by nix (subscriber, #2304) [Link]

The difference between a minimal version of qemu and the full version
isn't that much. You lose the CPU emulators, but a lot of hardware
emulation is still needed (for all the x86 hardware), and shares
essentially nothing with the kernel. How much of qemu is KVM-specific? Two
files plus a header? Maybe we could move just *them* in ;}

I agree with Anthony and Avi here. It looks like Ingo's hugely
underestimating the amount of work needed to go from the KVM kernel
interface to a working virtualization engine, and the only advantage that
perf had (easy ABI changes) really isn't something qemu should encourage,
particularly since it not only has to cope with all older ABI versions on
both sides of the kernel/userspace divide, but also emulation of
behavioural changes and even past bugs so that migration isn't broken.

But, hey, maybe Ingo's right. God knows he's pulled enough rabbits out of
hats before, many of which I would also have said were impossible before
he did it. :)