This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Discussion at Linux Foundation Japan Symposium


Theodore Tso wrote:
>>> This means no modules, since debuginfo is a disaster with modules
>>> (so helping people create configurations that don't use modules
>>> would be helpful);
>> Please elaborate what you mean.  Why systemtap is forced to use
>> (create) modules at all has been explained often.
> 
> What I mean is that if you build a kernel with a large number of
> modules, the bloat of systemtap becomes disastrous.  With a
> distro-style kernel, the compilation time literally goes up by a
> factor of 4-5 or so, and the disk space utilization goes up by a
> factor of 8 or so.  It's not so bad if you only the device drivers you
> into a single kernel, and not create any unneeded modules.  This is
> often not the common way at least some kernel developers build
> systems, since (a) modules make it easier to load and unload
> subsystems without rebooting, and this can shorten the
> compile-edit-debug cycle times, and (b) some kernel developers want to
> be sure they know whether any infrastructural changes they might cause
> some random device driver or other random subsystem to break.
> Unfortunately, building a distro-style kernel is a horrible disaster
> with debuginfo enabled, and so warning people off about this
> particular issue would be helpful.

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.


>> Sure, upstream changes in the location of Modules.marker are something
>> we can easily adapt to.  Are you aware of a current problem with that?
>> On the other hand, we plan to work on also connecting straight to
>> tracepoints, and to various slices of ftrace, for which a file such
>> the troubled-history Modules.markers will not be necessary.
> 
> Only that "make install" or "make modules_install" doesn't currently
> install Modules.marker anywhere useful.  And there is no standard
> location for where Modules.marker will be installed given current
> distribution packaging tools.  Attention to consumability of SystemTap
> given a variety of different kernel installation schemes is a Really
> Good Idea.  It's not just Fedora RPM-style macros and "make install".
> There are many other ways that people create and install kernels; and
> this kind of attention to detail will stop people from getting
> Frustrated with SystemTap.

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.

Thank you,

-- 
Masami Hiramatsu

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

e-mail: mhiramat@redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]