linux-kernel - Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <486B4BDA.4060203@firstfloor.org>
Date:	Wed, 02 Jul 2008 11:35:22 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>, Ingo Molnar <mingo@...e.hu>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	Andi Kleen <andi-suse@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325

Maciej W. Rozycki wrote:
> On Mon, 30 Jun 2008, Rafael J. Wysocki wrote:
> 
>> Well, there are lots of pieces of hardware that are not up to the
>> specifications, more or less, and I don't think that's a good enough reason
>> for us to refuse to support them.  The same applies to BIOSes IMO.
> 
>  Refusing to support broken hardware would provide some incentive to
> manufacturers to improve it, because people would rather not buy
> unsupported pieces of junk. 

For most consumer level hardware the vendors generally don't
really care if Linux runs on it or not.

Also they very rarely fix anything after release anyways because
they don't make enough money on it.

For server hardware that is different (vendors care about Linux,
but typically not about mainline, but about given RHEL/SLES  releases),
but even there we generally try to work around BIOS bugs
(at least as long as it is possible)
because it tends to be quite difficult logistically to require
a BIOS update. In the end it just hurts the user.

> I realise that may be impractical though 

It is.

> we would get the blame anyway, because "it runs the other OS just fine."

That is exactly what happens.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/