Re: [ltt-dev] [RFC patch 29/41] LTTng menus

Randy Dunlap
2009-03-06T00:13:36Z

Mathieu Desnoyers wrote:
> * Randy Dunlap (randy.dunlap@oracle.com) wrote:
>> Mathieu Desnoyers wrote:
>>> * Randy Dunlap (randy.dunlap@oracle.com) wrote:
>>>> Mathieu Desnoyers wrote:
>>>>
>>>> <<attachment :(>>
>>>>
>>>>
>>>> +menuconfig LTT
>>>> + bool "Linux Trace Toolkit Next Generation (LTTng)"
>>>> + depends on EXPERIMENTAL
>>>> + select MARKERS
>>>> + select TRACEPOINTS
>>>> + default y
>>>>
>>>> Not default 'y', please.
>>>>
>>> OK, so default n it is. But I plan to leave the main menu "sub-features" as
>>> default y, given that people get the standard features when they choose
>>> to enable the tracer. Hopefully this is ok ?
>> Sure, as long as it just enables viewing the menu and not adding
>> code to a growing kernel.
>>

I see what you mean now. Thanks for the details.

>
> I want to be sure to understand your point. Would be following be OK ?
>
> Menu [ ] Linux Trace Toolkit Next Generation (LTTng) ---> (default n)
>
> Within this menu, the following options enable various tracer modules,
> some of which are typically needed, except in some very specific tracer
> use :
>
> < > Linux Trace Toolkit Lock-Protected Data Relay (default n)
> (default y is planned to be used for the lockless data
> relay module, which is not posted as part of this patchset)
> [ ] Debug check for random access in ltt relay buffers (default n)
> <*> Linux Trace Toolkit Serializer (default y)
> -*- Linux Trace Toolkit Custom Serializer (default y)
> -*- Linux Trace Toolkit Trace Controller (default m)
> <*> Linux Trace Toolkit Tracer (default y)
> [ ] Align Linux Trace Toolkit Traces (default n, selected of
> !HAVE_EFFICIENT_UNALIGNED_ACCESS)
> [ ] Add event size field to LTT events for tracer debugging (default n)
> <M> Support logging events from userspace (default m)
> [*] Support trace extraction from crash dump (default y)
> [*] Linux Trace Toolkit Kprobes Support (default y)
>
> I understand from your answer above that just enabling the "LTTng"
> submenu should not activate any of these items, am I correct ?

Ideally one wouldn't add bloat to the kernel, but if someone enables
the top-level menu item, I'm OK with enabling others under it.

(not that we all consider the same things to be bloat ;)

--
~Randy