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?
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".
On Thu, Feb 7, 2013 at 1:13 PM, <Valdis.Kletnieks@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
On Thu, Feb 7, 2013 at 6:13 PM, <Valdis.Kletnieks@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
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%20Co... 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 <horserivers@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
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...
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.Kletnieks@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
participants (5)
-
Anuz Pratap Singh Tomar -
Greg Freemyer -
horseriver -
Peter Teoh -
Valdis.Kletnieks＠vt.edu