Re: [PATCH 2/3] tracing/kprobes: Make Kconfig dependencies generic

[Mike Frysinger <vapier.adi@gmail.com>]

On Thu, Feb 18, 2010 at 10:00, Heiko Carstens wrote:
> On Thu, Feb 18, 2010 at 09:01:12AM -0500, Mike Frysinger wrote:
>> On Thu, Feb 18, 2010 at 08:25, Heiko Carstens wrote:
>> > --- a/arch/Kconfig
>> > +++ b/arch/Kconfig
>> > @@ -123,6 +123,10 @@ config USE_GENERIC_SMP_HELPERS
>> >
>> >  config HAVE_REGS_AND_STACK_ACCESS_API
>> >        bool
>> > +       help
>> > +         This symbol should be selected by an architecure if it supports
>> > +         the API needed to access registers and stack entries from pt_regs.
>> > +         For example the kprobes-based event tracer needs this API.
>>
>> a bit vague ... arent there headers/functions people could look at ?
>> perhaps you're talking about the regset functions (which is an API to
>> access registers in pt_regs) ?  or you're talking about asm/syscall.h
>> (which is an API to access registers in pt_regs) ?
>>
>> i'm not asking to be a pain, i'm asking because i really havent a
>> clue.  if i wanted to add support for this stuff to the Blackfin arch,
>> i wouldnt know where to start.  even after reading this help i'd fall
>> back to grepping arch/x86/ and trying to divine a starting point from
>> there.
>
> git show b1cf540f would be your friend. That's why I pointed out the
> id in the changelog.
> I have no idea what your workflow is, but doing something like
> gitk v2.6.32..v2.6.33-rc1 arch/<whatever>/
> is what I do to figure out what other archs did during the merge
> window and if there's something that needs an arch backend on s390.
> This reveals also bug fixes that need to be ported from time to time.
> That worked pretty well for me during the last few years.

most of the time though such implementations are tied to the arch, and
for people unfamiliar with the arch in question, they can have a hard
time separating the common requirements from the arch requirements.
changelog entries also really shouldnt be the norm for documentation
of APIs, especially as APIs change over time (by design -- linux has
no stable API).  so while this commit may be useful for the next
release or two, it isnt uncommon for them to be partially if not
wholly irrelevant down the line.  which is when us smaller arches get
around to implementing this cooler features.
-mike