From: Andi Kleen <ak@suse.de>
To: Pavel Machek <pavel@suse.cz>
Cc: paul.devriendt@amd.com, davej@redhat.com,
linux-kernel@vger.kernel.org, aj@suse.de,
richard.brunner@amd.com, mark.langsdorf@amd.com
Subject: Re: Cpufreq for opteron
Date: 25 Aug 2003 12:56:04 +0200 [thread overview]
Message-ID: <p7365km57ln.fsf@oldwotan.suse.de> (raw)
In-Reply-To: <20030825084616.GC403@elf.ucw.cz.suse.lists.linux.kernel>
Pavel Machek <pavel@suse.cz> writes:
> Okay, but hopefully machines being sold in retail will have bug-free
> BIOSes?
That was a good one.
BIOS are _always_ buggy.
Especially on production boards, when someone far away butchered a BIOS
until it booted XP instead of knowing what he was doing.
> > I know the debug code is ugly ... but, I am expecting to need it. In the
> > next rev of the driver, when hardware is publicly for sale, we have some
> > degree of stability, etc ... then great. But, for now, releasing a driver
> > that has only been tested on prototype hardware ... and removing the
> > debug code. Ouch.
>
> If we want the code to be in 2.6.X final, it is good to start pushing
> it _now_. And we can't reasonably expect linus to eat patch with
> _that_ much debugging.
I don't see the problem, as long as the debugging code is a bit cleaned
up (no ifdefs in the functions itself). Also we have precendence
in some other subsystem that come with extensive debugging code.
Code ugliness comes from other things, not debugging code.
I think Paul's point - anything dependent on the BIOS should have a
a lot of self diagnosis support because BIOS are usually buggy - makes
a lot of sense. Otherwise one will have to add printks again
as needed, and that would be a waste of time.
-Andi
next parent reply other threads:[~2003-08-25 10:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <99F2150714F93F448942F9A9F112634C080EF006@txexmtae.amd.com.suse.lists.linux.kernel>
[not found] ` <20030825084616.GC403@elf.ucw.cz.suse.lists.linux.kernel>
2003-08-25 10:56 ` Andi Kleen [this message]
2003-08-27 0:43 Cpufreq for opteron paul.devriendt
2003-08-27 5:13 ` Dominik Brodowski
-- strict thread matches above, loose matches on Subject: below --
2003-08-25 14:09 paul.devriendt
2003-08-25 12:53 paul.devriendt
2003-08-25 13:51 ` Pavel Machek
2003-08-24 15:31 paul.devriendt
2003-08-25 9:35 ` Pavel Machek
2003-08-22 20:09 paul.devriendt
2003-08-25 8:46 ` Pavel Machek
2003-08-25 13:30 ` Valdis.Kletnieks
2003-08-22 16:25 Andi Kleen
2003-08-22 13:59 Pavel Machek
2003-08-22 14:43 ` Dave Jones
2003-08-22 19:55 ` Pavel Machek
2003-08-22 20:05 ` Pavel Machek
2003-08-26 23:02 ` Dominik Brodowski
2003-08-22 14:52 ` Christoph Hellwig
2003-08-22 14:55 ` Dave Jones
2003-08-22 19:54 ` Pavel Machek
2003-08-23 7:55 ` Rogier Wolff
2003-08-23 17:50 ` Christoph Hellwig
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=p7365km57ln.fsf@oldwotan.suse.de \
--to=ak@suse.de \
--cc=aj@suse.de \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.langsdorf@amd.com \
--cc=paul.devriendt@amd.com \
--cc=pavel@suse.cz \
--cc=richard.brunner@amd.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