Trap number: how a system software recognise it

Hi

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 buttist me...

PART1 ---------- buttume 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 readstb. readstb 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 readstb 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 buttociated 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 buttigned 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 buttociated with a File Control Block that contains the file's 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