linux-kernel - Re: 2.6.22-rc1-mm1: IDE compile error

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]

Date:	Thu, 24 May 2007 17:18:34 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: 2.6.22-rc1-mm1: IDE compile error

Alan Cox wrote:
> I believe the technical description for the comment is "bullshit" 8)
> 
> Almost all MFM controllers and RLL controllers will only run at the
> standard primary and secondary ATA address.

Yes, but that doesn't (necessarily) apply to the controller that is
likely to be the primary controller in a modern system.

The whole point is that what the BIOS considers primary isn't
necessarily tied to the standard ATA addresses anymore, with SATA
controllers being primary.

The question I'm asking is: do you think it's better to remove this from
hd.c, or do you think it's better to add it back boot code BIOS
detection (and take the risk of poking an ST-506 disk with legacy data
with parameters which may belong to another disk -- keep in mind this
can permanently damage an ST-506 disk)?

> Given the intended use of the driver today I don't see a big problem in
> requiring "hd=" although you have to question the point of this boot code
> rewrite when it seems primarily to be removing features 

I've been trying to remove features that are obsolete and/or broken.  I
don't have access to this particular ancient hardware, nor any system
that can even host them.   It's very easy to add the stuff back in the
boot code; it's a much more tricky/annoying question if one *should* do
so.  That's part of a rewrite/cleanup.

	-hpa
-
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/