All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randy Dunlap" <rdunlap@xenotime.net>
To: Adrian Bunk <bunk@stusta.de>,
	Arjan van de Ven <arjan@infradead.org>,
	Sam Ravnborg <sam@ravnborg.org>, Dave Jones <davej@redhat.com>,
	linux-ide@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: tighten ATA kconfig dependancies
Date: Sun, 16 Jul 2006 11:14:22 -0700	[thread overview]
Message-ID: <1153073662.7604@shark.he.net> (raw)



> On Sat, Jul 15, 2006 at 08:45:56AM +0200, Arjan van de Ven wrote:
> > On Sat, 2006-07-15 at 08:38 +0200, Sam Ravnborg wrote:
> > > On Sat, Jul 15, 2006 at 07:49:08AM +0200, Arjan van de Ven wrote:
> > > > On Sat, 2006-07-15 at 01:34 -0400, Dave Jones wrote:
> > > > > A lot of prehistoric junk shows up on x86-64 configs.
> > > > 
> > > > 
> > > > ... but in general it helps compile testing if you're hacking stuff;
> > > > if your hacking IDE on x86-64 you now have to compile 32 bit as
well to
> > > > see if you didn't break the compile for these as well
> > > > 
> > > > So please don't do this, just disable them in your config...
> > > 
> > > An i686 cross compile chain seems to be the natural choice here
> > 
> > the point is that it doesn't fall out naturally, and thus things get
> > needlessly missed.
> 
> It seems the main question is:
> Is the kernel configuration mainly designed for users or for developers?
> 
> For users, showing drivers for hardware that is not present on their 
> platform only causes confusion.
> 
> Only developers who want to do compile tests could benefit from 
> compiling such drivers.
> 
> IMHO the kernel configuration is mainly designed for users.

or at least should be.

> We could do some kind of (X86_32 || DEVELOPER_COMPILE_TEST).

Let's not complicate it more.

> Or simply disable this driver on other platforms - these are only 
> compile errors and amongst all possible problems in the kernel compile 
> errors are amongst my least worries (obvious error, usually quickly 
> fixed after the first bug report).


---
~Randy

             reply	other threads:[~2006-07-16 18:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-16 18:14 Randy Dunlap [this message]
     [not found] <6yL2J-7rR-1@gated-at.bofh.it>
     [not found] ` <6yLco-7DB-1@gated-at.bofh.it>
2006-07-15 18:38   ` tighten ATA kconfig dependancies Bodo Eggert
2006-07-16  5:58     ` Sam Ravnborg
2006-07-16  6:04       ` Arjan van de Ven
2006-07-16  6:17         ` Sam Ravnborg
  -- strict thread matches above, loose matches on Subject: below --
2006-07-15  5:34 Dave Jones
2006-07-15  5:49 ` Arjan van de Ven
2006-07-15  6:38   ` Sam Ravnborg
2006-07-15  6:45     ` Arjan van de Ven
2006-07-15 10:28       ` Adrian Bunk
2006-07-15 10:56         ` Arjan van de Ven
2006-07-16  9:13           ` Adrian Bunk
2006-07-24  3:05 ` Alan Cox

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=1153073662.7604@shark.he.net \
    --to=rdunlap@xenotime.net \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=bunk@stusta.de \
    --cc=davej@redhat.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.