hd controller
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! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: hd controller
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? In this procedure , what work does the hd driver do ? You may wish to get a copy of 'Linux Device Drivers, 3rd Edition' and read it before posting lots of questions here. A free version is available online, and last I checked it was the very first hit if you google for 'Linux device drivers. pgp6PLoWn0vWf.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: hd controller
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 does the controller know a new command has received? In this procedure , what work does the hd driver do ? You may wish to get a copy of 'Linux Device Drivers, 3rd Edition' and read it before posting lots of questions here. A free version is available online, and last I checked it was the very first hit if you google for 'Linux device drivers. Be sure to read about scatter/gather list processing at the disk controller level. I believe most hd controllers these days can accept an array of pointers that tells it where to find (place) date for writes (reads). It would be the drivers responsibility to build the scatter/gather meta information to be compatible with what the controller specs call for. There is a little info about that here: http://www.makelinux.net/books/ulk3/understandlk-CHP-14-SECT-1 Greg ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: hd controller
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 does the controller know a new command has received? In this procedure , what work does the hd driver do ? You may wish to get a copy of 'Linux Device Drivers, 3rd Edition' and read it before posting lots of questions here. A free version is available online, and last I checked it was the very first hit if you google for 'Linux device drivers. This! Please read LDD, LKD and ULK fully before asking questions. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Thank you Warm Regards Anuz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: hd controller
at the lowest level, SCSI/IDE/SATA all shared a common command base
(perhaps with variations) - which is ATA command (because in
drivers/ata/*.c u can find the symbol ATA_XXX_CMD in all the three
different hardware architecture):
Below is a an example specified by standard body (these command are OS
agnostic):
https://github.com/gcastigl/SO2C2011TP2/blob/master/doc/ATA%20-%20ATAPI%20Command%20Set.pdf
Look at all the ATA_CMD_* command here:
https://github.com/Scorpiion/Renux_u-boot/blob/master/include/ata.h
So the drivers just literally concatenate these command into a string and
send it over to the device.
for example in drivers/ata/libata-core.c:
static int ata_read_native_max_address(struct ata_device *dev, u64
*max_sectors)
{
unsigned int err_mask;
struct ata_taskfile tf;
int lba48 = ata_id_has_lba48(dev-id);
ata_tf_init(dev, tf);
/* always clear all address registers */
tf.flags |= ATA_TFLAG_DEVICE | ATA_TFLAG_ISADDR;
if (lba48) {
tf.command = ATA_CMD_READ_NATIVE_MAX_EXT;
tf.flags |= ATA_TFLAG_LBA48;
} else
tf.command = ATA_CMD_READ_NATIVE_MAX;
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 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!
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Regards,
Peter Teoh
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: hd controller
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 memory management (make sure that everybody's data ends up in the right buffers), command queue management, elevator management (if there's multiple I/O requests pending from userspace, what order do we issue them in?), error recovery, power management, and a ton of other stuff... pgpLQscp6zy4D.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: hd controller
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. drivers/scsi/*.c: generally SCSI protocol related stuff (lib*.c), but may contain device specific stuff. drivers/ide/*.c: drivers/ata/*.c: among the lowest level just before sending out port I/O operation. On Fri, Feb 8, 2013 at 8:26 AM, valdis.kletni...@vt.edu wrote: 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 memory management (make sure that everybody's data ends up in the right buffers), command queue management, elevator management (if there's multiple I/O requests pending from userspace, what order do we issue them in?), error recovery, power management, and a ton of other stuff... -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
