Re: [PATCH 1/2] kbuild: Add "Section mismatch" warning whitelist for powerpc

["Satyam Sharma" <satyam.sharma@gmail.com>]

On 5/15/07, Li Yang-r58472 <LeoLi@freescale.com> wrote:
> > [...]
> > Actually, once __init_refok comes in, would we need any other
> > whitelisting mechanism at all? I think the exception patterns in
> > secref_whitelist() and those two other whitelisting functions
> > (init_section_ref_ok and exit_section_ref_ok) could all be
> > subsumed and made redundant if / when __init_refok is used
> > in the actual sources.
>
> I don't think so.  __init_refok can be used to mark special functions
> which are legitimate to reference .init.text/.init.data

But I have slightly different (reversed) semantics for __init_refok
in mind. Basically, we use __init_refok to annotate _callees_
and not _callers_. In short, __init_refok is a _type_ of __init
section that other sections can freely reference to, without
modpost complaining about this. [ had suggested this in some
previous thread earlier ]

The __init_refok-for-callees mechanism could be useful to
reduce duplication, having to mark lesser number of functions,
and also make most of those exception patterns in modpost.c
redundant.

Ultimately, we want modpost to shut up for some known false
positives. Currently we have 9 exception patterns, 'n' number
of special sections hard-coded in modpost.c, 3 whitelisting
functions and also the __init_refok thing that can be used
directly to mark functions in the sources. But modpost
doesn't really care _how_ a particular case got whitelisted.

Using _only_ the __init_refok (easily greppable in the sources)
annotation for callees could help keep all such special cases
manageable and in control, compared to several different ways
to dodge modpost warnings.

> but cannot be used to mark special sections.

Yes, so mark the special _callees_ as __init_refok.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/