Request Handlers (IRQ, vector tables)

[KC]

K I posted this in software, and got nothing and it's been days so mods please don't freak out, if we delete something lets remove the one from software -------k--------

I need to know what a request handler is:

As far as I know example: Hardware (keyboard) sends IRQ to CPU, listens then it looks for a request handler in the vector table, I take that this is some code that tells it what to do with the request from the hardware and I also think that this code is located in the memory ie ram, rom ect.

K is the above correct and were in the memory (range) are these things located? you know like fffff-aaaaa.

Thanks for the help.

[thumper]

Here are a few link that might help with what you're looking for.

I/O Address Summary Map

Device Resource Summary

IRQ Details

[KC]

thanks thumper

[KayMan2K]

Hey,

I guess there aren't many very technical people on the board. Hopefully I can clear up a few things. I am basing my answers on a machine running Windows / DOS because that is what I have studied. I am sure the same applies to Linux though.

There are three ways an interupt can be called / raised, by an operating system, by hardware, or specifcially by a program. You have mentioned the example of the user pressing a key and causing the keyboard to send data to the computer. This actually raises a hardware interrupt. The term IRQ (which stands for nothing) simply refers to the interrupt number of a certain call. (I do not know off hand what the keyboard is.. it is in the top 12 though). Those interrupts, labeled IRQs, are separately monitored and controlled by two separate chips located on the motherboard (you will notice that no hardware could ever be placed on IRQ2. This is because IRQ2 is a bridge between the two controllers).

The CPU does not constiantly check to see if an interrupt has been called. It is not effecient. Parallel this to a classroom of students. Is it more effeiceint for the professor to constantly ask the students one by one if they have a question? or just let them raise a hand. This is what the interrupts do when they need processor attention.. they "raise their hand" to the IRQ controller chips which notify the CPU that attention is needed. Then the CPU haults execution... runs the software associated with the IRQ.. and resumes.

I beleive you are curious to know how the CPU gets notified? I learned that this is done in hardware and there really isn't a memory location that gets changed which the CPU monitors.

I do not know where you heard what you know from.. but I can defintly say that the vector table does not contain any program data or anything that would indicate a flag. the vector table (full name: Interrupt Vector Jump Table) is a list of 256 addresses in memory for standardized functions.. such as print screen and divide by zero. Each interrupt is a 4-byte memory pointer to where the software associated with the call is. This is all part of the operating system and more used in DOS. Although I think this method can be used to fool a lot of Windows XP protected memory locations.

For example the print screen function is interrupt 5. So when the button is pressed the IRQ controllers notify the CPU and then runs the code at location 5.

I would also assume that if there is a way to monitor CPU interrupts (i know you can disable and enable them using assembly code) it would be done in the port i/o space and not accessable by a standard segment::offset memory location.

I am curious about what you are trying to do. It sounds like your trying to make a keylogger. In this case you would want to mask the keyboard interrupt (or change the function pointer in the vector jump table) to point to your code which logs the keystroke and then returns the key input to the original function. It is not a simple task.

I hope this helps.

[KayMan2K]

  Quote

Originally posted by thumper

Here are a few link that might help with what you're looking for.

I/O Address Summary Map

Device Resource Summary

IRQ Details

Yes. This is the port I/O I mentioned.. and you can see the locations of data the ports use. You will need to know how to acces the port I/O memory space though since it is different than that of the main memory.

The definition of IRQ is good... but mine is more accurate. That an IRQ is just a shorthand for several interrupts. There are many more interrupts than there are IRQs.

[KC]

K this is what i have in my book.

step 1. A key is pressed on the keyboard. The keyboard controller raises its assigned IRQ (1) to the cpu, saying "I need attention." the cpu sees the IRQ, acknowledges it and turns its attention to servicing it. By sending the acknowledgment, it is requesting the device controller sends a number called an interrupt (abbreviated INT) that tells the cpu what service the device needs.

Step2. The keyboard controller sends INT 9 to the cput. The cpu uses this value to locate the program to handle the interrupt. This program, shich may be either BIOS or a device driver is called an interrupt handler.

Step3. The cpu looks to a table in RAM called the interrupt vector table or vector table, that contains a list of memory address locations of interrupt handlers. The INT value passed to the CPu by the controller points to service the keyboard (a portion of system BIOS) are stored.

Step4. The CPU Looks to the location in memory of the request handler and begins to follow the instructions there.

step5. The cput following the interrupt handler instructions processes the keystroke.

now the above makes sense to me, but on my work sheet i have a question "Describe a request handler. Where in memory can you find a list of addresses where request handlers are located?"

my book has a list of the interrupt value's but not where they would be located at. So all in all I need to know where in memory (as the book says over and over but does not list) the vector table is.

[KayMan2K]

Yeah. It looks up the interupt location and runs whatever code it is pointing to.

[KC]

the book also says that the INterrupt vector table is a table that stores the momory addresses assigned to interrupt handlers also called a vector table.

So I imaging that the interrupt handlers arnt perment but the vector table has a perment location and is more like a index in a boox.

[KC]

and i don't think that this apply's to NT/2000 and maybe XP cuz I don't think those o.s.'s define conventional, upper, or extended memory.

[KayMan2K]

That is a great annology. The vector jump table is a index to a book. The book being the operating system. Since every OS uses different programming and takes up different amounts of space, the location of each interrupt handler is different with every operating system. However, the vector jump table doesn't change its location (which starts at 0000:0000 in memory). An interrupt handler is a function which is called when the interrupt occurs. So it is what the pointer in the table points to.

Example is the print screen function. Its memory location is different in windows 95 and windows xp... so you can see its entry in the table is different... like you said.. its on a different memory "page" in the book of ram.

[KayMan2K]

  Quote

Originally posted by kxgard3

and i don't think that this apply's to NT/2000 and maybe XP cuz I don't think those o.s.'s define conventional, upper, or extended memory.

It actually does apply. Those operating systems may not have a set definition for areas of memory.. but the location of the function MUST exist somewhere in memory and the only way for the cpu to know that is using the vector jump table.

Every OS (at least on the pc), uses such a method. Dos, Windows 1,2,3,3.11,95,98,NT,2K,XP, Unix, Linux, BeOS, etc...

The vector table is a property of the pc hardware.. not a specific operating system.

[KC]

Great I think we figured it out. Thanks kayman2k you helped alot.

[KayMan2K]

Ok.. I saw your book post just now. The book's definitions are exactly correct. Your question is where is the interupt vector jump table? It is in the very beginning of memory.. at location 0. It spans for 1024 bytes. The book's use of the aberviation INT is actually reffering to the assembly level intel instruction code to call an interrupt through software.

[KayMan2K]

Yeah :D :D :D

Glad I was able to help.

[KC]

sweet thanks.