Re: Discussion at Linux Foundation Japan Symposium

[Masami Hiramatsu <mhiramat@redhat.com>]

Theodore Tso wrote:
> 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.

OK, so kernel developers would better configure reducing or embedding
drivers as much as possible, since the amount of debuginfo strongly
depends on the number of modules. That's a good tip.

> 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.

Thank you for a good advice. I think, at least, we might have to
clarify what optimizations will effect to line-by-line probing.

I also heard that -fno-inline-functions-called-once which is
enabled by CONFIG_DEBUG_SECTION_MISMATCH enables us to access
the parameters of some 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 .

Additionally, if users want to use markers in their out-of-tree
driver, they will have another Module.marker file in the local
(module build) directory. :-)

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com