lkml.org 
[lkml]   [2005]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/39] NLKD - early/late CPU up/down notification
On Thu, Nov 10, 2005 at 08:41:32AM +0100, Jan Beulich wrote:
> >>> Greg KH <greg@kroah.com> 09.11.05 18:19:19 >>>
> >On Wed, Nov 09, 2005 at 06:09:27PM +0100, Jan Beulich wrote:
> >> >>> Greg KH <greg@kroah.com> 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).

When you try to load the module, you will get the error again, right in
your kernel/system log, which explicitly shows that you had a 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...

Don't try to do things to fix your prior problems in your patch, with
changes today so that you don't do it again in the future :)

The build process properly notifies the builder of the problem, if they
ignore it, there's really nothing more we can do about it, right?

thanks,

greg k-h
-
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/

\
 
 \ /
  Last update: 2005-11-11 00:21    [W:0.132 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site