public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Hazelton <dhazelton@enter.net>
To: Andi Kleen <andi@firstfloor.org>
Cc: "Parag Warudkar" <parag.warudkar@gmail.com>,
	"Adrian Bunk" <bunk@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: How to reduce the number of open kernel bugs
Date: Fri, 2 May 2008 13:40:42 -0400	[thread overview]
Message-ID: <200805021340.42508.dhazelton@enter.net> (raw)
In-Reply-To: <87od7ovcpj.fsf@basil.nowhere.org>

On Friday 02 May 2008 13:27:04 Andi Kleen wrote:
> Daniel Hazelton <dhazelton@enter.net> writes:
> >  If the hardware works
> > perfectly in every other OS
>
> It depends. There used to be the famous case (not longer true now) that
> older Linux allocated memory from the top of the memory down and other OS
> generally allocated it the from bottom to up and when some of your top
> memory was broken Linux would often hit problems where other OS did not.

True.

> Also there can be the case when some OS use hardware quite differently
> or different hardware features than other. Standard case for example
> used to be that there were a few platforms where the SMM code had 64bit
> bugs and of course you would only hit them when running a 64bit OS which
> was Linux.

Sadly things like this will continue as long as there is a single OS that has 
more than a 70% market share of the common desktop market.

> A modern OS is a very complicated system with tens of millions of code
> lines and you can't assume they all program the hardware in the same way.
>
> Simple truths are often wrong.

Yes, but if the hardware *ISN'T* broken, then claiming it is and closing out a 
bug is the wrong thing to do. The right thing to do would be to find out why 
the hardware isn't working correctly for the OS/driver combination in 
question and, if possible, fix the driver.

>  - and possibly even previous versions of Linux -
>
> Now that is a more interesting case. But regressions are always taken
> seriously by all maintainers I know.
>

Look to the bug-report posted (cleaned of evidence that would incriminate any 
single person) by (IIRC) Adrian. The guy says "It worked with X and works in 
Windows, but it now fails with message Z."

Maintainer says "Your hardware is broken", closes the bug and then goes on to 
say "If the hardware isn't broken, talk to the people in charge of A and B 
because my code isn't buggy."

That is idiotic and immature.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.

  reply	other threads:[~2008-05-02 17:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 14:42 How to reduce the number of open kernel bugs Parag Warudkar
2008-05-02 15:11 ` Adrian Bunk
2008-05-02 16:29 ` Daniel Hazelton
2008-05-02 17:27   ` Andi Kleen
2008-05-02 17:40     ` Daniel Hazelton [this message]
2008-05-02 17:30   ` Parag Warudkar
2008-05-02 17:44     ` Daniel Hazelton
2008-05-02 17:48       ` Rafael J. Wysocki
2008-05-02 18:18         ` Andi Kleen
2008-05-02 23:10           ` Daniel Hazelton
2008-05-02 18:01     ` Adrian Bunk
2008-05-02 18:25       ` Parag Warudkar
2008-05-02 23:15       ` Daniel Hazelton
  -- strict thread matches above, loose matches on Subject: below --
2008-05-02 12:42 Adrian Bunk
2008-05-03 10:13 ` SL Baur
2008-05-03 11:21   ` Adrian Bunk
2008-05-03 12:00     ` SL Baur
2008-05-03 15:43     ` Stefan Richter
2008-05-03 15:48       ` Stefan Richter
2008-05-05 18:12       ` Adrian Bunk

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=200805021340.42508.dhazelton@enter.net \
    --to=dhazelton@enter.net \
    --cc=andi@firstfloor.org \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parag.warudkar@gmail.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