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 11:53:40 -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:
>>> hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44aad): undefined reference to `drive_info'
>>> drivers/built-in.o:hd.c:(.init.text+0x44ab9): more undefined references to `drive_info' follow
>>> make[1]: *** [.tmp_vmlinux1] Error 1
>>>
>>> <--  snip  -->
>>>
>>> Considering the fact that we have two more recent drivers with the same 
>>> functionality, it might be an option to simply remove this driver...
>> Care to send a patch?
> 
> hd.c can drive MFM and RLL disks and drivers/ide cannot. Although it
> really wants burying further down the config tree the ability to read MFM
> and RLL disks when recovering ancient data is useful and people do
> actually use this driver now and then rescuing stuff like twenty year old
> datasets.
> 
> It thus needs fixing not removing.

Why is this driver parked in drivers/ide/legacy when the companion
driver, xd.c, is in drivers/block (where hd.c used to be at one point,
too)?  Especially so since it's not really for IDE, but for ST-506.

HOWEVER, the code that fails above hard-assumes that the ST-506 disks
that you have are your primary system drives, which is obviously a wrong
assumption -- ST-506 drives were obsolete quite a while before Linux
existed[1].

xd.c, on the other hand, seems to actually go out and query the hardware
directly.  I guess this is understandably, since this controller would
never have been primary.

If hd.c is pure legacy, which it obviously is, should we remove the code
to assume the BIOS settings are the MFM/RLL settings (i.e. the __i386__
clause), and instead do something more like the __arm__ clause which
means that "if you really want to use this you have to specify the
parameters manually"?

	-hpa

[1] The 386-16 that I had access to at Northwestern, which with 0.59
BogoMIPS was the slowest Linux system in existence until Linux was
ported to other architectures, might have been an ST-506 drive, but I'm
not sure.
-
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/