Messages in this thread | | | Date | Thu, 10 Nov 2005 15:01:26 -0800 | From | Greg KH <> | Subject | Re: [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/
| |