Re: [PATCH 3/39] NLKD - early/late CPU up/down notification

[Jan Beulich]

>>> Greg KH <greg@xxxxxxxxx> 09.11.05 18:19:19 >>>
>On Wed, Nov 09, 2005 at 06:09:27PM +0100, Jan Beulich wrote:
>> >>> Greg KH <greg@xxxxxxxxx> 09.11.05 17:45:44 >>>
>> >#ifdef in the .h file is not needed.  Please fix your email client
to
>> >send patches properly.
>> 
>> It's not needed, sure, but by having it there I just wanted to make
>> clear that this is something that never can be called from a module
>> (after all, why should one find out at modpost time (and maybe even
miss
>> the message since there are so many past eventual symbol resolution
>> warnings) when one can already at compile time.
>
>If it isn't present, and you do a build, you will still get the error
at
>build time, just during a different part of it.  Adding #ifdef just
to
>move the error to a different part of the build isn't needed. 
Remember,
>we want to not use #ifdef at all if we can ever help it.

I understand that. But you don't see my point, so I'll try to explain
the background: When discovering the reason for the kallsyms change
(also posted with the other NLKD patches) not functioning with
CONFIG_MODVERSIONS and binutils between 2.16.90 and 2.16.91.0.3 I
realized that the warning messages from the modpost build stage are very
easy to overlook (in fact, all reporters of the problem overlooked them
as well as I did on the first build attempting to reproduce the
problem). This basically means these messages are almost useless, and
detection of the problem will likely be deferred to the first attempt to
load an offending module (which, as in the case named, may lead to an
unusable kernel). Hence, at least until this build problem gets
addressed I continue to believe that adding the preprocessor conditional
is the better way of dealing with potential issues. Sure I know that
hundreds of other symbols possibly causing the same problem aren't
protected...

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/