1
$\begingroup$

I am wondering how disk addresses are accessed from a program. From my understanding, the two main facilities are programmed I/O (instructions) and memory-mapped I/O (simply loads and stores). The second is usually just loads and stores into a specific part of memory that maps into the device.

  • Is it common for memory-mapped I/O to encompass the whole disk address space or just specific device registers? Can the locations of these memory addresses overlap with valid RAM addresses?
  • How does the disk expose the "block interface" to the kernel and at what level of memory management is this handled?
  • How do you address these blocks and how does this all work?
Improve this question
$\endgroup$
1

1 Answer 1

Reset to default
1
$\begingroup$

User programs generally do not "address" disk directly. Nor is the data from disk mapped into address space.

The general way that data is transferred between disk and memory is via DMA. Many disk host controllers also provide a slower way to do it as well using memory-mapped I/O registers or I/O ports, to make things simpler for firmware to boot an operating system.

See my previous answer for more on the how and why of DMA.

How a driver exposes disk transfers to the rest of the kernel is highly specific to the operating system. Typically, a modern operating system dedicates as much non-allocated memory as it can to be used by buffer cache; essentially, a cached copy of disk blocks. So the "operation" that a driver exposes essentially initialises a DMA request to a page frame of buffer cache, and then notifies the operating system when the request has completed.

Improve this answer
$\endgroup$
5
  • $\begingroup$ So from my understanding, there is a specific protocol (that you mention in the other answer) for doing so, and you are saying that is the typical interface (what exactly is this interface? Is it like programmed I/O?)? What about the disk controller and "block" interface? Is the kernel driver responsible for that, or the firmware in the disk controller? Does the rest of the operating system then address these blocks? I know you can view them in \dev in Linux ... $\endgroup$
    – user129393192
    Commented Jun 13, 2023 at 4:33
  • $\begingroup$ @user129393192 Here's the API in Linux as one example. elixir.bootlin.com/linux/latest/source/include/linux/… The submit_bio operation starts a block I/O operation. This is sometimes called the "strategy" operation; I believe Unix used that term for some reason). $\endgroup$
    – Pseudonym ♦
    Commented Jun 13, 2023 at 4:51
  • $\begingroup$ I've always found Linux code difficult to digest. So it seems like the driver communicates with the firmware and implements the "block" interface for the rest of the kernel. $\endgroup$
    – user129393192
    Commented Jun 13, 2023 at 4:54
  • $\begingroup$ @user129393192 Correct. And yes, Linux code can be a little tricky; you might find the IDE driver from xv6 easier to read, though it's much simpler because it doesn't use DMA. github.com/mit-pdos/xv6-public/blob/master/ide.c $\endgroup$
    – Pseudonym ♦
    Commented Jun 13, 2023 at 5:10
  • $\begingroup$ I see. I'd actually heard of the IDE disk interface. So you talk to a disk controller that responds to inb and outb loads and stores to its device registers and you poll it as necessary, busy waiting for the data to be read ... and then you manage those sectors as "blocks" on some higher level and expose it to the higher levels of the kernel (filesystem, etc) $\endgroup$
    – user129393192
    Commented Jun 13, 2023 at 5:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.