hi:)
I am curious about how hd controller work .
When user am reaing/writing hd ,it was implemented by sending command
to hd controller's special port.Then ,how does the controller know
a new command has received?
In this procedure , what work does the hd driver do ?
thanks
On Thu, 07 Feb 2013 16:19:33 +0800, horseriver said:
hi:)
I am curious about how hd controller work .
When user am reaing/writing hd ,it was implemented by sending command
to hd controller's special port.Then ,how does the controller know
a new command has received
On Thu, Feb 7, 2013 at 1:13 PM, valdis.kletni...@vt.edu wrote:
On Thu, 07 Feb 2013 16:19:33 +0800, horseriver said:
hi:)
I am curious about how hd controller work .
When user am reaing/writing hd ,it was implemented by sending command
to hd controller's special port.Then ,how
On Thu, Feb 7, 2013 at 6:13 PM, valdis.kletni...@vt.edu wrote:
On Thu, 07 Feb 2013 16:19:33 +0800, horseriver said:
hi:)
I am curious about how hd controller work .
When user am reaing/writing hd ,it was implemented by sending command
to hd controller's special port.Then ,how
;
the tf.command data within is ultimately send by port I/O operation.
BUT.not sure of details, corrections welcome :-).
On Thu, Feb 7, 2013 at 4:19 PM, horseriver horseriv...@gmail.com wrote:
hi:)
I am curious about how hd controller work .
When user am reaing/writing hd ,it was implemented
On Fri, 08 Feb 2013 07:48:39 +0800, Peter Teoh said:
So the drivers just literally concatenate these command into a string and
send it over to the device.
The reason that good disk drivers are hard to write is because it isn't
*just* literally concatenating the commands - it also has to do
good sharing. following up on your comments:
in the kernel source:
block/*.c are the files for block I/O related stuff - the layer just before
ATA, implementing stuff like elevator I/O etc.
drivers/block/*.c: hardware-specific files that understand how to talk to
each type of harddisk.
