linux-kernel - Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

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, 17 Apr 2008 10:05:06 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Tejun Heo <htejun@...il.com>
Cc:	Frans Pop <elendil@...net.nl>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Subject: Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

On Thu, Apr 17, 2008 at 07:12:35AM +0900, Tejun Heo wrote:
> Asking when no harddisk is detected w/ the option to choose it 
> explicitly should do for most cases.  No?

I suppose it might, although I could still see an older machine have a
PCI controller as well as an ISA legacy controller on an ISA sound card,
and might even have a CDROM drive connected to the sound card.  Not very
likely though, but not imposible.  In that case you might detect the HD
connected to the HD, but not the CDROM connected to the sound card.
That might be confusing to the user.  On the other hand anyone running
such old hardware might just have a pretty good idea what they are doing
and could run in expert mode and tell the installer to also load the
generic driver.

I still think the correct solution is to always try loading it, posibly
with a boot option to make the installer not do so for any machines that
have issues with that.  Any such machines should then have bug reports
filed so that the driver that runs their chipset's IDE controller in a
native mode can ensure they reserve the legacy IDE ports so that nothing
else (like the generic driver) can go poking at them.

After all I thought the whole point of all the ports listed in
/proc/ioports was to indicate which io ports were currently reserved by
which driver so that no other driver could try to access them.  If it
doesn't in fact work that way then it probably should.

-- 
Len Sorensen
--
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/