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

From: Jan Beulich (JBeulich_at_novell.com)
Date: 11/10/05

  • Next message: Jens Axboe: "Re: [PATCH] blk: cfq forced dispatching fix"
    Date:	Thu, 10 Nov 2005 08:41:32 +0100
    To: "Greg KH" <greg@kroah.com>
    
    

    >>> 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). 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Jens Axboe: "Re: [PATCH] blk: cfq forced dispatching fix"

    Relevant Pages

    • Re: [PATCH 3/39] NLKD - early/late CPU up/down notification
      ... > warnings) when one can already at compile time. ... we want to not use #ifdef at all if we can ever help it. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 3/39] NLKD - early/late CPU up/down notification
      ... >> not functioning with ... >> realized that the warning messages from the modpost build stage are ... re-issued at the end of the module building process (i.e. after the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [2.6 patch] drivers/acpi: remove unused exported functions
      ... > future patches, but sometimes Real Life gets in the way and the ... > programmer stalls development for some time, no problem, just ifdef it. ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Cpufreq for opteron
      ... > The fact most of users are already inside ifdef blocks themselves ... I converted lprintk and tprintk to dprintk. ... When do you have a heart between your knees? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [PATCH 2/3] RCU: rcu_assign_pointer() removal of memory barriers
      ... * substituting pointer. ... must be visible to another weakly ordered CPU before ... #ifdef CONFIG_NET_ESTIMATOR ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)