All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Tomas Szepe <szepe@pinerecords.com>, Adrian Bunk <bunk@fs.tum.de>,
	John Bradford <john@grabjohn.com>,
	Riley@Williams.Name, Linux-Kernel@vger.kernel.org
Subject: Re: [2.6 patch] let broken drivers depend on BROKEN{,ON_SMP}
Date: Wed, 13 Aug 2003 11:31:45 -0400	[thread overview]
Message-ID: <20030813153144.GA10579@gtf.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1030813104305.11041B-100000@gatekeeper.tmr.com>

On Wed, Aug 13, 2003 at 10:50:12AM -0400, Bill Davidsen wrote:
> On Thu, 31 Jul 2003, Tomas Szepe wrote:
> 
> > There are going to be a zillion drivers that don't compile by the
> > time 2.6.0 is released, which is precisely when lkml will see a whole
> > new wave of people willing to fix things so I really don't think
> > hiding the problems behind CONFIG_BROKEN or whatever is reasonable.
> 
> I can't follow your logic. This is now supposed to be a stable kernel, but
> you want to have a bunch of non-working drivers available to reduce
> confidence in it? If I have device X, why do you think I would need a
> driver less if it were marked BROKEN? A broken list would be a great
> starting point for people who are looking for something to do in 2.6.
> 
> If you get a bunch of compiler errors without a clear indication that the
> driver is known to have problems, it is more likely to produce a "Linux is
> crap" reaction. With the problems Windows is showing this week, I'd like
> to show Linux as the reliable alternative, not whatever MS is saying about
> hacker code this week.

The people who want Linux to be reliable won't be compiling their own
kernels, typically.  Because, the people that _do_ compile their own
kernels have sense enough to disable broken drivers :)  That's what Red
Hat, SuSE, and others do today.

	Jeff




  reply	other threads:[~2003-08-13 15:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-30  9:11 [2.6 patch] let broken drivers depend on BROKEN{,ON_SMP} John Bradford
2003-07-30 10:44 ` Adrian Bunk
2003-07-30 16:04   ` Tomas Szepe
2003-07-30 16:18     ` Adrian Bunk
2003-07-31  9:15       ` Tomas Szepe
2003-08-02 19:47         ` Adrian Bunk
2003-08-13 14:50         ` Bill Davidsen
2003-08-13 15:31           ` Jeff Garzik [this message]
2003-08-13 19:17             ` Adrian Bunk
2003-08-13 21:06             ` Bill Davidsen
2003-08-17  9:39               ` Rob Landley
2003-08-18 23:03                 ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2003-08-17 21:27 John Bradford
2003-08-14  5:28 John Bradford
2003-08-13 20:40 John Bradford
2003-08-13 21:03 ` Adrian Bunk
2003-07-31  9:41 John Bradford
2003-08-02 19:48 ` Adrian Bunk
2003-07-30 11:29 John Bradford
2003-07-30 11:37 ` Adrian Bunk
2003-07-30 11:53   ` Jan Evert van Grootheest
2003-07-29 19:59 Adrian Bunk
2003-07-30  7:44 ` Riley Williams

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=20030813153144.GA10579@gtf.org \
    --to=jgarzik@pobox.com \
    --cc=Linux-Kernel@vger.kernel.org \
    --cc=Riley@Williams.Name \
    --cc=bunk@fs.tum.de \
    --cc=davidsen@tmr.com \
    --cc=john@grabjohn.com \
    --cc=szepe@pinerecords.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 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.