HELP! Question about System calls when reading a HDD

[Oobie-]

Hey guys,

Ive got a question to answer, but I'm slightly stumped about where to start and what to talk about, so I was wondering if you could help me.

The question:

Disk transfers are carried out using DMA and an interrupt is raised when the operation completes.
Explain what happens in the Operating System between a user application making a system call to
read sector 50 from disk and the data being returned to the user's buffer, indicating any process scheduling that occurs, change in processor state, use of memory buffers, etc.



Thanks.

[aidanjt]

Pick an easy question why not?

Quickest and easiest way to learn is read fdisk's source code and the disk i/o syscalls & subsystems in the linux kernels sources, if you really want to know the nitty gritty.

In laymans terms, the application operates at the block level using the kernels IOCTRL syscall, like read n blocks from block x on dev /dev/sdy, the kernel figures out what subsystem that block device uses from an internal struct table, instructs the driver to perform the required operation and blocks the app, the implementation from here varies from one i/o controller to another, but generically the CPU leaves instructions in ram, and sends an IRQ to the controller with a pointer to the memory location, the device reads the commands, executes them, passes even lower level (S)ATA commands to the HDD, which reads in the required data into the buffer, streams the data to the controller which in turn streams it into the ram buffer specified by the kernel, and sends an IRQ to the CPU that the commands were executed, or halted due to full a buffer, giving it time to read the memory in from ram into a separate buffer in userspace allocated by the app, then unblocks the app. E&OA

[Oobie-]

aha. Looks convincing!

Just looking at each bit and trying to expand now. Thanks aidanjt.
We're talking about how linux is handling this system call, as I'm assuming that windows may do it slightly differently?

[aidanjt]

It may well do slightly, but I've never bothered to explore windows internal kernel stuff, it's much easier finding freely available documentation and source code for linux, so i'd stick with that for kernel/hardware interaction theory.

[Oobie-]

ah ok cool.

Is there a link handy that you could supply me that has fdisk's source code, please?

[aidanjt]

Sure, it's part of the util-linux package, you can download it from: Index of /pub/linux/utils/util-linux-ng

Obviously you can download the kernel sources from the same site if you browse backwards through the http server.

[Oobie-]

Hmmmm, just as I suspected. Unfortunately my knowledge in C and C++ isn't strong enough to understand that source code, haha.

So that code is executed by the kernal, and in it, is how system calls are handled?

Could I confirm a few things from your original post -
whats /dev/sdy
when the cpu leaves instructions in the ram - do you mean it leaves the application instructions in the ram or something else?
and
the pointer to the memory location - thats the pointer to the said application for returning to it (if my above statement is correct?)

Thanks

[aidanjt]

Sorry, been working hard the last few days.

The code is executed by the app, the apps syscalls trigger the running of code that already exists in the kernel, it's much the same as using the fopen() libc function for opening files, but at a lower kernel and hardware level interaction, it bypasses ordinary virtual filesystem cache, filesystem implimentation, and libc.

In linux, nearly all hardware devices are represented by virtual files called device nodes, the location for SCSI (or SATA/Generic) disks are at /dev/sd? where '?' is a letter starting from a to z.

Command passing in storage devices is a bit like leaving the plans for building something in a certain part of the building, then you send the storage device a simple message saying where you left the set of commands needed to complete the job. So basically, a pointer is just a variable that points to where another (set or single) variable is.

Hope it helps clarify.