* SATA passthrough commands from User Space
@ 2008-12-11 8:05 Muhammad Mutahir Latif
2008-12-11 8:30 ` Jeff Garzik
0 siblings, 1 reply; 3+ messages in thread
From: Muhammad Mutahir Latif @ 2008-12-11 8:05 UTC (permalink / raw)
To: linux-kernel
Hi
I am new to linux kernel development and need help in developing an
application in linux for a SATA device. What is required is that the
application needs to send raw SATA commands along with data (like Read
DMA, Write FPDMA etc) to a SATA hard disk. Secondly we also have to
achieve a reasonably high data transfer throughput.
As a starting point I was thinking of modifying the AHCI driver by
adding an IOCTL hook to the driver , through which the user space
application would be able to send command and data to the drive. The
IOCTL function in the driver on getting a command would prepare the
appropriate structures, prepare memory buffers and then call other
builtin AHCI functions to perform the operations. Is this the correct
approach for handling such a problem or should we be looking at the
libata and use functions from that module. I would really appreciate
any help from someone who might have modified AHCI or libata so that
raw SATA commands can be sent from the user space
Thanks
Mutahir
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SATA passthrough commands from User Space
2008-12-11 8:05 SATA passthrough commands from User Space Muhammad Mutahir Latif
@ 2008-12-11 8:30 ` Jeff Garzik
2008-12-15 13:55 ` Muhammad Mutahir Latif
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Garzik @ 2008-12-11 8:30 UTC (permalink / raw)
To: mutahirlatif; +Cc: linux-kernel
Muhammad Mutahir Latif wrote:
> Hi
>
> I am new to linux kernel development and need help in developing an
> application in linux for a SATA device. What is required is that the
> application needs to send raw SATA commands along with data (like Read
> DMA, Write FPDMA etc) to a SATA hard disk. Secondly we also have to
> achieve a reasonably high data transfer throughput.
Use the existing SG_IO ioctl.
Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SATA passthrough commands from User Space
2008-12-11 8:30 ` Jeff Garzik
@ 2008-12-15 13:55 ` Muhammad Mutahir Latif
0 siblings, 0 replies; 3+ messages in thread
From: Muhammad Mutahir Latif @ 2008-12-15 13:55 UTC (permalink / raw)
To: linux-kernel
Thank you Jeff for the SG_IO suggestion. Are there any numbers as to
the average throughput achieved using the SG_IO ioctl. The reason I am
asking is that for our scenario the data transfer throughput required
might not be fulfilled using the SG_IO ioctl due to the SCSI->ATA
translations. In case the SG_IO does not fulfill the requirement,
where should we add IOCTL functionality. At first I was thinking of
adding it to the AHCI driver, but by looking at the code I saw that
the ahci driver only implements functions so that they can be hooked
with the libata framework, so should I add IOCTL hooks to the
libata?. Please let me know if I am by any chance going completely in
the wrong direction.
Thanks
Mutahir
On Thu, Dec 11, 2008 at 1:30 PM, Jeff Garzik <jeff@garzik.org> wrote:
> Muhammad Mutahir Latif wrote:
>>
>> Hi
>>
>> I am new to linux kernel development and need help in developing an
>> application in linux for a SATA device. What is required is that the
>> application needs to send raw SATA commands along with data (like Read
>> DMA, Write FPDMA etc) to a SATA hard disk. Secondly we also have to
>> achieve a reasonably high data transfer throughput.
>
> Use the existing SG_IO ioctl.
>
> Jeff
>
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-12-15 13:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-11 8:05 SATA passthrough commands from User Space Muhammad Mutahir Latif
2008-12-11 8:30 ` Jeff Garzik
2008-12-15 13:55 ` Muhammad Mutahir Latif
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox