Konkle, Timothy A wrote:
Jeff,
Hopefully this is an easy, quick question…
I am trying to write code to stress test/diagnose SATA SSD drives under
AHCI (on Linux obviously).
It seems for speed and certain types of info (physical link, HBA
settings and such), that I want to switch user level code from
sg3_util/sg.ko down to changes directly in the ahci.ko module. Does
this seem correct?
Basically, I am trying to first issue COMReset to particular drives for
instance (from a python script->shared lib C code), then reset bus and
adjust speed and more… Pointers on locations to make code
modifications? I was expecting to find an ioctl() like mechanism in
ahci.c much like the scsi/sg modules… I am using kernel 2.6.24, though
I can use later kernels too. Basically I am trying to build up a test
and validation shared library that will be call able from python code
and see controllers, devices, command lists, FIS data and build out a
test library with data collection and COMReset as first stop.
I’m just starting through device driver development with books such as
Linux Device Drivers 3^rd ed, Essential Linux Device Drivers (can’t find
that book’s code) and many others. So it seems that I have most data
I’d need to reset a device in ahci.ko and just add in a /proc interface
for user control to request a device reset via it’s HBA controller. Is
ahci.c a poor choice as it is controller/used by higher level drivers
such as libata, sd or other modules?
Is there already source code in Linux that shows how to do this sort of
thing? Everything I’ve seen so far uses slower and a bit higher level SG.
Support for online diagnostics and testing within libata is quite
limited, since that is not needed by the majority of our users.
The SG_IO ioctl and SCSI-specified ATA(12) and ATA(16) commands specify
various types of resets. Changes to libata to support these resets
would probably be the easiest initial change, and least amount of work.
Dumping full internals is probably not something we would want in the
kernel driver -- too much code space for too little user value -- but
something like networking's ETHTOOL_GREGS would be reasonable for SATA
drivers. Userspace could handle things from there.
Other controls like per-port SATA phy controls we have wanted for a
while; the appropriate place to put those is in sysfs, not procfs.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
