linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
	linux-kernel@vger.kernel.org, len.brown@intel.com,
	linux-acpi@vger.kernel.org, michael@free-electrons.com
Subject: Re: 2.6.25-rc2-mm1 (x64 thermal build failure)
Date: Mon, 18 Feb 2008 11:15:36 +0100	[thread overview]
Message-ID: <20080218111536.511c4fbc@crazy> (raw)
In-Reply-To: <20080216214410.b9699910.akpm@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]

Hi,

Le Sat, 16 Feb 2008 21:44:10 -0800,
Andrew Morton <akpm@linux-foundation.org> a écrit :

> Bustage in x86-configurable-dmi-scanning-code.patch.  Previously,
> DMI=y was just hardwired.  Now, it becomes selectable and stuff
> breaks.
> 
> I guess the DMI=n version of dmi_check_system() could become a macro
> so we don't emit a reference to its argument, but that might generate
> unused-variable warnings elsewhere.

Thanks for your report. The issue is that some DMI fixup tables and
callbacks are defined inside #ifdef CONFIG_DMI, some others are not. We
need to normalize that to fix the build issue in all situations.

I've thought about it, and I see two options, but I can't decide which
one is the best, so I request your opinion on that.

 1) Remove the #ifdef CONFIG_DMI around DMI fixup tables and callbacks
    definition, so that everything exists and gcc is happy. gcc is able
    to optimize out the DMI fixup table (it is not present in the binary
    when compiling with DMI=n), but gcc doesn't seem to be able to
    optimize out the DMI fixup callbacks (they are still present in the
    binary). So this would leave some unused code in the binary, which
    is not completely satisfying.

 2) Define macros such as DECLARE_DMI_FIXUP_TABLE and
    DECLARE_DMI_FIXUP_CALLBACK, which could then be used like this:

DECLARE_DMI_FIXUP_CALLBACK(set_bios_reboot, __init, d, {
	if (reboot_type != BOOT_BIOS) {
		reboot_type = BOOT_BIOS;
		printk(KERN_INFO "%s series board detected. Selecting BIOS-method for reboots.\n", d->ident);
	}
	return 0;
});

DECLARE_DMI_FIXUP_TABLE(reboot_dmi_table, __initdata, {
	{	/* Handle problems with rebooting on Dell E520's */
		.callback = set_bios_reboot,
		.ident = "Dell E520",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
			DMI_MATCH(DMI_PRODUCT_NAME, "Dell DM061"),
		},
	}
});

     And use them everywhere, so that DMI fixup tables and callbacks
     are properly compiled out when DMI=n. Here are the macro definition:

#ifdef CONFIG_DMI

#define DECLARE_DMI_FIXUP_TABLE(name, opts, contents...) \
	static struct dmi_system_id opts name [] = contents

#define DECLARE_DMI_FIXUP_CALLBACK(name, opts, id, contents...) \
	static int opts name(const struct dmi_system_id *id) contents

#else

#define DECLARE_DMI_FIXUP_TABLE(name, opts, contents...)

#define DECLARE_DMI_FIXUP_CALLBACK(name, opts, contents...)

#endif

     The issue I have with this option is that there are sometimes
     "driver_data" associated to DMI callbacks (see
     drivers/input/misc/wistron_btns.c for example) and I don't exactly
      see how to create a similar DECLARE_DMI_FIXUP_CALLBACK_DATA macro.

Thanks for your insights,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Free Embedded Linux Training Materials
on http://free-electrons.com/training
(More than 1500 pages!)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2008-02-18 10:16 UTC|newest]

Thread overview: 134+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-16  8:25 2.6.25-rc2-mm1 Andrew Morton
2008-02-16 10:59 ` 2.6.25-rc2-mm1: build failure (x86) Marcin Slusarz
2008-02-16 11:09   ` Andrew Morton
2008-02-16 11:37     ` Marcin Slusarz
2008-02-17  0:22       ` Rafael J. Wysocki
2008-02-17  9:54         ` Marcin Slusarz
2008-02-17  1:37       ` Rafael J. Wysocki
2008-02-17  9:56         ` Marcin Slusarz
2008-02-19 18:51           ` Russell Leidich
2008-02-16 16:15 ` [BUG] 2.6.25-rc2-mm1 - kernel oops while bootup on s390x Kamalesh Babulal
2008-02-16 19:45   ` Andrew Morton
2008-02-16 19:49     ` Thomas Gleixner
2008-02-16 19:50       ` Thomas Gleixner
2008-02-17  3:40         ` Kamalesh Babulal
2008-02-17  9:06           ` Heiko Carstens
2008-02-18 14:08             ` Kamalesh Babulal
2008-02-16 17:21 ` 2.6.25-rc2-mm1 Randy Dunlap
2008-02-16 17:31 ` [PATCH]2.6.25-rc2-mm1 - Build Failure at security/keys/compat.c on powerpc Kamalesh Babulal
2008-02-16 17:48 ` 2.6.25-rc2-mm1 (wakeup) Randy Dunlap
2008-02-17  1:18   ` Rafael J. Wysocki
2008-02-17  1:22     ` H. Peter Anvin
2008-02-17  2:19       ` Randy Dunlap
2008-02-17  3:58         ` H. Peter Anvin
2008-02-17  4:38           ` [PATCH v2] " Randy Dunlap
2008-02-17  4:35             ` H. Peter Anvin
2008-02-17  4:47               ` Randy Dunlap
2008-02-17 20:40                 ` Rafael J. Wysocki
2008-02-17 21:07                   ` Sam Ravnborg
2008-02-17 21:21                     ` H. Peter Anvin
2008-02-17 21:28                       ` Sam Ravnborg
2008-02-17 21:31                         ` H. Peter Anvin
2008-02-17 21:46                           ` Sam Ravnborg
2008-02-17 21:20                   ` H. Peter Anvin
2008-02-16 19:47 ` [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os Kamalesh Babulal
2008-02-16 20:01   ` Laura Garcia
2008-02-21  7:08   ` Len Brown
2008-02-21 18:54     ` Nish Aravamudan
2008-02-21 22:22       ` Sam Ravnborg
2008-02-22  1:38         ` Nish Aravamudan
2008-02-22 18:08           ` Sam Ravnborg
2008-02-22 18:12             ` Nish Aravamudan
2008-02-22 18:13             ` Randy Dunlap
2008-02-22 18:21               ` Nish Aravamudan
2008-02-22 18:27               ` Sam Ravnborg
2008-02-22 18:29                 ` Randy Dunlap
2008-02-22 18:56                   ` Sam Ravnborg
2008-02-22 19:25                     ` [PATCH] " Randy Dunlap
2008-02-23  5:41                       ` Len Brown
2008-02-23 15:33                       ` Kamalesh Babulal
2008-02-16 21:27 ` 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129 Laurent Riffard
2008-02-16 21:52   ` Arjan van de Ven
2008-02-18  4:58     ` Brown, Len
2008-02-18  5:18       ` Arjan van de Ven
2008-02-18 19:35   ` Arjan van de Ven
2008-02-18 21:05     ` Laurent Riffard
2008-02-18 21:12       ` Arjan van de Ven
2008-02-24  0:44   ` Gabriel C
2008-02-24  2:50     ` Arjan van de Ven
2008-02-25 16:31       ` Gabriel C
2008-02-25 22:44         ` Arjan van de Ven
2008-02-25 23:33           ` Gabriel C
2008-02-25 23:59             ` Gabriel C
2008-03-01 15:40               ` Mirco Tischler
2008-03-02 15:53           ` Fabio Checconi
2008-03-02 16:58             ` Arjan van de Ven
2008-03-03  8:46               ` Ingo Molnar
2008-03-03  8:47                 ` Ingo Molnar
2008-03-03 10:21                 ` Fabio Checconi
2008-03-02 20:40             ` Laurent Riffard
2008-03-02 23:35               ` Mirco Tischler
2008-02-17  4:10 ` [BUG] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit() Kamalesh Babulal
2008-02-17  4:50   ` Andrew Morton
2008-02-17  5:02     ` Kamalesh Babulal
2008-02-17 12:41   ` Oleg Nesterov
2008-02-20 19:34   ` Rik van Riel
2008-02-20 20:04     ` Oleg Nesterov
2008-02-20 22:53       ` Rik van Riel
2008-02-28 13:13         ` Cedric Le Goater
2008-02-20 20:07     ` Alan Cox
2008-02-17  5:08 ` 2.6.25-rc2-mm1 Kamalesh Babulal
2008-02-17  5:24   ` 2.6.25-rc2-mm1 Andrew Morton
2008-02-17  7:36     ` 2.6.25-rc2-mm1 Kamalesh Babulal
2008-02-17  5:16 ` 2.6.25-rc2-mm1 (x64 thermal build failure) Randy Dunlap
2008-02-17  5:44   ` Andrew Morton
2008-02-18 10:15     ` Thomas Petazzoni [this message]
2008-02-18 12:13       ` Andrew Morton
2008-02-19 15:55         ` Thomas Petazzoni
2008-02-19 17:41           ` Randy Dunlap
2008-02-19 22:00             ` Thomas Petazzoni
2008-02-19 22:05               ` Randy Dunlap
2008-02-19 23:21           ` Andrew Morton
2008-02-20  7:21             ` Thomas Petazzoni
2008-02-20  9:55               ` Andrew Morton
2008-02-17  5:32 ` 2.6.25-rc2-mm1 (build failure) Randy Dunlap
2008-02-17  5:46   ` Andrew Morton
2008-02-17 19:52     ` Pavel Machek
2008-02-17 20:12       ` Rafael J. Wysocki
2008-02-17 11:23   ` Rafael J. Wysocki
2008-02-17 17:54     ` Randy Dunlap
2008-02-17  6:25 ` 2.6.25-rc2-mm1 Joel Becker
2008-02-17  6:32   ` 2.6.25-rc2-mm1 Joel Becker
2008-02-17  6:51   ` 2.6.25-rc2-mm1 Andrew Morton
2008-02-17 10:50 ` 2.6.25-rc2-mm1: new create_proc_entry() users Alexey Dobriyan
2008-02-18 13:01   ` Andrew Morton
2008-02-18 16:13   ` Daniel Walker
2008-02-19 22:25   ` Miller, Mike (OS Dev)
2008-02-19 23:59     ` Andrew Morton
2008-02-18  0:14 ` 2.6.25-rc2-mm1 (cifs build errs) Randy Dunlap
2008-02-18  4:10   ` Steve French
2008-02-18  0:16 ` 2.6.25-rc2-mm1 Randy Dunlap
2008-02-18  9:34   ` 2.6.25-rc2-mm1 Andrew Morton
2008-02-18  5:17 ` 2.6.25-rc2-mm1 (x86 MCE build error) Randy Dunlap
2008-02-18  6:03   ` Yinghai Lu
2008-02-18 13:31   ` Adrian Bunk
2008-02-18 17:13 ` 2.6.25-rc2-mm1 (cciss " Randy Dunlap
2008-02-19  0:08 ` 2.6.25-rc2-mm1 Kevin Winchester
2008-02-19  0:15   ` 2.6.25-rc2-mm1 Andrew Morton
2008-02-19  0:22     ` 2.6.25-rc2-mm1 Steven Rostedt
2008-02-19  1:15       ` 2.6.25-rc2-mm1 Kevin Winchester
2008-02-20 21:14 ` 2.6.25-rc2-mm1 - several bugs and a crash Tilman Schmidt
2008-02-20 21:50   ` Patrick McHardy
2008-02-21 11:28   ` Patrick McHardy
2008-02-21 16:32     ` Stephen Hemminger
2008-02-21 16:34       ` Patrick McHardy
2008-02-22  0:40     ` Tilman Schmidt
2008-02-22  0:52       ` Tilman Schmidt
2008-02-22 17:09         ` Paul E. McKenney
2008-02-25  8:54           ` Tilman Schmidt
2008-02-27 16:37     ` nf_conntrack fix smp_processor_id() in preemptible code (was: 2.6.25-rc2-mm1 - several bugs and a crash) Tilman Schmidt
2008-02-27 16:47       ` nf_conntrack fix smp_processor_id() in preemptible code Patrick McHardy
2008-02-21 12:38   ` 2.6.25-rc2-mm1 - several bugs and a crash Andrew Morton
2008-02-21 16:46     ` Christoph Hellwig
2008-02-22  0:10       ` Tilman Schmidt
2008-02-21 19:36     ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080218111536.511c4fbc@crazy \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=akpm@linux-foundation.org \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@free-electrons.com \
    --cc=randy.dunlap@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).