lkml.org 
[lkml]   [2008]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH -next] bug.h: add empty warn_on_slowpath() for CONFIG_BUG=n
On Tue, 1 Jul 2008 15:23:38 -0500 (CDT)
Randy Dunlap <randy.dunlap@oracle.com> wrote:

> --- Original Message ---
> > On Tue, 1 Jul 2008 10:33:39 -0700
> > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >
> > > From: Randy Dunlap <randy.dunlap@oracle.com>
> > >
> > > Add an empty function for warn_on_slowpath() when CONFIG_BUG=n so that
> > > this build error does not happen:
> > >
> > > linux-next-20080701/drivers/acpi/utilities/utmisc.c: In function 'acpi_ut_error':
> > > linux-next-20080701/drivers/acpi/utilities/utmisc.c:1028: error: implicit declaration of function 'warn_on_slowpath'
> > >
> > > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> > > ---
> > > include/asm-generic/bug.h | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > --- linux-next-20080701.orig/include/asm-generic/bug.h
> > > +++ linux-next-20080701/include/asm-generic/bug.h
> > > @@ -81,4 +81,9 @@ extern void warn_on_slowpath(const char
> > > # define WARN_ON_SMP(x) do { } while (0)
> > > #endif
> > >
> > > +#ifndef __ASSEMBLY__
> > > +static inline void warn_on_slowpath(const char *file, const int line)
> > > +{ }
> > > +#endif
> > > +
> > > #endif
> > >
> >
> > This looks like a needed-in-mainline fix? or is there something
> > in linux-next which causes the bug?
>
> Looks like only linux-next has this code:
>
> > > linux-next-20080701/drivers/acpi/utilities/utmisc.c: In function 'acpi_ut_error':
> > > linux-next-20080701/drivers/acpi/utilities/utmisc.c:1028: error: implicit declaration of function 'warn_on_slowpath'
>

err...


commit 9e030ab0bffdc8b6d8be663b639bd5e2374537f0
Author: Len Brown <len.brown@intel.com>
Date: Tue Jun 24 22:47:09 2008 -0400

ACPI: add standard linux WARN_ON() output to ACPI errors and exceptions

In linux-2.6.27, we expect WARN() with printk semantics
to become available, and we'll be able to simplify
this code.

Signed-off-by: Len Brown <len.brown@intel.com>

diff --git a/drivers/acpi/utilities/utmisc.c b/drivers/acpi/utilities/utmisc.c
index 1f057b7..0a340b0 100644
--- a/drivers/acpi/utilities/utmisc.c
+++ b/drivers/acpi/utilities/utmisc.c
@@ -1028,6 +1028,7 @@ acpi_ut_error(char *module_name, u32 line_number, char *format, ...)
{
va_list args;

+ warn_on_slowpath(module_name, line_number);
acpi_os_printf("ACPI Error (%s-%04d): ", module_name, line_number);

va_start(args, format);
@@ -1042,6 +1043,7 @@ acpi_ut_exception(char *module_name,
{
va_list args;

+ warn_on_slowpath(module_name, line_number);
acpi_os_printf("ACPI Exception (%s-%04d): %s, ", module_name,
line_number, acpi_format_exception(status));


Was there any particular reason for doing it this way? It's really
quite wrong, given that an architecture can provide its own definition
of WARN_ON() and __WARN() and might not even implement
warn_on_slowpath() at all.

The usual way of doing this is to go in via the front door: WARN_ON(1).


\
 
 \ /
  Last update: 2008-07-01 22:39    [W:0.043 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site