Hi! On Fri, 10 May 2013 19:00:31 +0200, Samuel Thibault <samuel.thiba...@gnu.org> wrote: > AHCI is indeed not too complex, I've just pushed an AHCI driver to > gnumach master. I'm currently successfully building a glibc with it.
:-)
> I have only tested with kvm for now. Actual bare hardware test is for
> later.
So, I was curious about the card I have in my Hurd box:
Silicon Image SteelVine
SiI3114CTU
QS6829.1-13
0815
AD0AX2
$ sudo lspci -nn
[...]
00:0a.0 RAID bus controller [0104]: Silicon Image, Inc. SiI 3114
[SATALink/SATARaid] Serial ATA Controller [1095:3114] (rev 02)
[...]
<https://ata.wiki.kernel.org/index.php/Sata_sil>. That one identifies
itself as a RAID device (0104, PCI_CLASS_STORAGE_RAID), but your code
currently on scans for "real" SATA 0106 ones. Note that I'm not actually
interested in the (software) RAID functionality
(<https://ata.wiki.kernel.org/index.php/SATA_RAID_FAQ#I_have_a_Silicon_Image_SATA_RAID_card._Why_doesn.27t_Linux_support_my_hardware_RAID.3F>).
Assuming that it can be handled/accessed without needing any RAID stuff,
and looking at the current Linux kernel code (drivers/ata/sata_sil.c),
this shouldn't be difficult to get working (and I'll give it a try later
on), but I wonder what the goal with our support of AHCI/SATA in GNU Mach
is. Because, if we want to generally claim support, would we (have to)
end up re-implementing all the quirks/fixes for the individual devices
that are already addressed in the Linux kernel, for example? Or are
these more or less only for legacy devices that nobody any longer cares
about (but then, my SiI3114 card probably is ten years old, too, and more
recent ones surely also have their issues)?
Would glueing in libata en bloc be an option? Without having looked in
detail, I could imagine this to be a sensibly isolated subsystem with not
too many external interfaces?
Grüße,
Thomas
pgp5vIxqc6qk_.pgp
Description: PGP signature
