From: "Randy.Dunlap" <rddunlap@osdl.org>
To: Andries Brouwer <aebr@win.tue.nl>
Cc: akpm <akpm@osdl.org>,
ak@suse.de, lkml <linux-kernel@vger.kernel.org>,
greg@kroah.com
Subject: Re: [PATCH] PCI: fix build errors with CONFIG_PCI=n
Date: Tue, 16 Nov 2004 15:36:30 -0800 [thread overview]
Message-ID: <419A8EFE.8060508@osdl.org> (raw)
In-Reply-To: <20041116232600.GB2868@pclin040.win.tue.nl>
Andries Brouwer wrote:
> On Tue, Nov 16, 2004 at 02:34:48PM -0800, Randy.Dunlap wrote:
>
>>Fix (most of) kernel build for CONFIG_PCI=n. Fixes these 3 errors:
>>
>>1. drivers/parport/parport_pc.c:3162: error: `parport_init_mode'
>>undeclared (first use in this function)
>
>
> Life is easier if you do not use attachments.
> (Then I can more easily comment the code.)
I understand. If the decision were only so simple.
> You write
>
> -static int __init parport_init_mode_setup(const char *str) {
> -
> +#ifdef CONFIG_PCI
> +static int __init parport_init_mode_setup(const char *str)
>
> In my tree I have
>
> static int __init parport_init_mode_setup(char *str) {
>
> in order to avoid the warning for
>
> __setup("parport_init_mode=",parport_init_mode_setup);
>
> since the parameter is a int (*setup_func)(char *); - see
>
> struct obs_kernel_param {
> const char *str;
> int (*setup_func)(char *);
> int early;
> };
Yes, I'm familiar with that, but I made a patch against current
top of tree.
> Apart from this prototype change I only moved the single line
>
> static int __initdata parport_init_mode = 0;
>
> outside the #ifdef's. Is that not good enough, and better
> than introducing more #ifdef's? Keeps the source smaller.
It can be good enough. It keeps the source smaller, at
the expense of adding some unneeded code (the
parport_init_mode_setup() function e.g.).
--
~Randy
next prev parent reply other threads:[~2004-11-17 0:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-16 22:34 Randy.Dunlap
2004-11-16 23:26 ` Andries Brouwer
2004-11-16 23:36 ` Randy.Dunlap [this message]
2004-11-17 0:16 ` Andries Brouwer
2004-11-17 0:13 ` Randy.Dunlap
2004-11-17 0:32 ` Andries Brouwer
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=419A8EFE.8060508@osdl.org \
--to=rddunlap@osdl.org \
--cc=aebr@win.tue.nl \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®