Re: Discussion at Linux Foundation Japan Symposium

[Theodore Tso <tytso@MIT.EDU>]

On Mon, Dec 22, 2008 at 06:34:11PM -0500, Masami Hiramatsu wrote:
> 
> Hmm, why would you think all or nothing?
> 
> I agreed with your opinion that the kernel compilation time longer
> if we configure more drivers compiling as modules.
> 
> However, even if you build all required modules into the kernel,
> you can still enable module support. So, I think it's not an issue.

Yes, that's what I was talking about; my apologies for not being
clear.  So what I do when I want to use debuginfo is I build a single
reduced-functionality kernel, with only device drivers I need built
into the kernel, but I allow modules because SystemTap requires them.
My suggestion was *documenting* this in the Wiki to make it clear that
(a) debuginfo sucks and terribly bloats with lots of modules, and (b)
developers who want to use SystemTap with debuginfo would be well
advised to avoid using large numbers of modules.  This is the kind of
usability issue that SystemTap is badly lacking.

Also, if you want to advertise using line-by-line probes as a
SystemTap feature, you might want to suggest a kernel patch that
disables gcc optimizations such that probes have a half-way decent
chance of actually working.  Yes it violates the SystemTap religion
about never needing to recompile the kernel; but it recognizes the
reality that the gcc toolchain has incredibly sucky debuginfo that
doesn't take into account CSE, function reordering, and inlining of
static functions.

> Hm, perhaps, we should support an option or environment variable to
> specify (several) path of Modules.marker. After fixing that path, we can
> deprecate the option.

There are only a few places where it can go; one is
/boot/Module.marker-<kver>; another is
/lib/modules/<kver>/Module.markers.  The last
place is /lib/modules/<kver>/build/Module.marker .

							-Ted