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:	Sun, 06 Jan 2013 22:30:01 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
CC:	Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: delete super ancient PC-XT driver for 1980's hardware

On 01/04/2013 07:27 PM, Paul Gortmaker wrote:
> This driver was for the 8 bit ISA cards that were installed in
> the PC-XT machines of 1980 vintage.  They supported the dual
> ribbon cable MFM drives of 10-20MB capacity, and ran at a 3:1
> interleave, giving performance on the order of 128kB/s.
>
> By the introduction of the PC-AT (286) these controllers were
> already scrapped in favour of 16 bit controllers with some onboard
> RAM that could support a 1:1 interleave.
>
> The git history doesn't show any evidence of runtime fixes that
> would reflect active usage; instead just the usual tree-wide API
> type changes/cleanups.  Going back to in-source changelogs, the
> last "runtime" fix that is evident is something I did over a
> dozen years ago[1] -- and even back then, the hardware was long
> since unavailable, so that ancient fix was also not runtime tested.
>
> The time is long overdue for this to get flushed, so lets get
> rid of it before anyone wastes more time doing builds and sparse
> checks etc. on long since dead code.

Although this hardware is obviously long obsolete, it's conceivable that 
someone could still drag out an old MFM/RLL controller and run it on a 
non-completely-ancient PC with ISA slots in order to recover data from 
an old drive or something. Given that the code doesn't have wide-ranging 
effects beyond a couple of files, I'd lean towards keeping it unless 
there's some reason to believe it's hopelessly broken.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ