Hi,
I wish to be personally CC'ed the answers/comments posted to the list in
response to this post
I have done some reading about system calls and memory management but some
issues are not yet that clear for me, so I hope some of you will assist
me...
PART1
--
Assume within a C user program there is a read (fid, buf, nbytes) procedure
call. According to Tanenbaum book, this will call a C-system read function
or what is known as C-stub function read_stb.
read_stb includes some initial instructions and in particularly a trap
number to make a system call to the Kernel. This number will be used to
index the trap vector or table stored in the kernel in order to retrieve the
address of the trap handler routine which performs the read operation.
My question is how the read_stb knew about the trap number used by the
kernel to perform read operation from the device?
Although my question refers to c library, my question holds for other system
softwares that might perform the same operation.
Does the reading operation from a disk have a fix trap number? What about
other I/O peripherals (scanner, webcam, digital camera, printer)
For the above peripherals, we need generally to install a device driver. If
we take the scanner as an example and say the user wants to zoom out a
scanned section. This operation is associated with some initial instructions
and a system call through a trap number call. This trap number will be used
to point to the relevant device driver routine as explained above.
Will this variable get assigned a value during the installation of
peripheral device drivers?
We know that each device has its interface commands that the kernel can
call. Each procedure will be stored at a particular location in the kernel
memory. Once saved, I presume that the OS updates its trap table and
allocate a trap number to each device procedure. Is that right?
What about the devices which are recognised without installing device
drivers, have they a fixed location and trap numbers? Is this documented for
whoever want to write a device driver?
PART 2
--
The main CPU initiates the I/O operation by instructing the device
controller with a high level commands (writing to the device registers and
so on). Such high level commands are then translated to lower instruction by
the device controller. Then it is up to the device processor to take these
commands and branch to the relevant device driver code at the kernel space
to perform the low level instructions. Upon completion an interrupt will be
sent to the CPU to flag (hopefully) the completion of the task.
So could we deduce that the device processor have *full* access to the
kernel memory (fill privileges)?
If we take as an example: reading a block of data from a stored file. Each
file is associated with a File Control Block that contains the files
metatdata, i.e. among others the description of file organisation.
Will the command sent by the CPU to the disk controller (after inspecting
the file FCB) be similar to RETRIEVE BLOCK X. and this will be translated by
the device controller to cylinder C, PLATTER P, SECTOR S?
What about if the OS wants to retrieve more block. Will just be written into
the device controller memory?
Many thanks
_
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
