LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 09-04-2011, 01:50 AM   #1
Marnix
LQ Newbie
 
Registered: Sep 2011
Posts: 3

Rep: Reputation: Disabled
How does the interrupt handler of a device know which process to wake up?


I will explain my question.

Say process 1 and process 2 want to read data from say a hard disk drive (but my question can be about any device). Process 1 is interested in data X residing on the device and process 2 is interested in data Y residing on the device. The kernel will pass each read request to the device driver for the device. The driver will issue some I/O commands to the device after which the driver puts the process to sleep (it needs to wait for the device to finish retrieving the data).

When the device has retrieved the data it issues an interrupt. This is a a-synchronous event. The interrupt handler knows nothing about the process for which the data is meant (how can it know that?). It puts the data in some kernel buffer I presume. How does the handler or kernel know to which user process (process 1 or 2) the data must be passed?

Or is a device used by one process at a time and will any read() call of another process only be passed to the driver if the first process has been served? But then I do not understand books about the kernel which talk about wait queues for devices and that when an interrupt occurs the handler wakes up every process in the queue! I don't understand how this can work.

Obviously I misunderstand something. Can someone please explain to me the process.
 
Old 09-04-2011, 08:20 AM   #2
onebuck
Moderator
 
Registered: Jan 2005
Location: Summer Midwest USA, Central Illinois, Winter Central Florida
Distribution: Slackware®
Posts: 13,565
Blog Entries: 34

Rep: Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738
Hi,

Welcome to LQ!

The article 'Dynamic Interrupt Request Allocation for Device Drivers' may clear things up for you.

The above link and others can be found at 'Slackware-Links'. More than just Slackware® links!

"Knowledge is of two kinds. We Know a subject ourselves, or we know where we can find information upon it."- Samuel Johnson

 
Old 09-04-2011, 10:02 AM   #3
Marnix
LQ Newbie
 
Registered: Sep 2011
Posts: 3

Original Poster
Rep: Reputation: Disabled
Thanks, I read it but it doesn't clarify it.

The author writes "Typically, the ISR wakes up sleeping processes on the device if the interrupt signals the event for which they are waiting."

But say process 1 is waiting for file1 (say sectors 1 and 2) on the hard drive to be retrieved from disk and process 2 is waiting for file2 (say sectors 3 till 5) on the hard drive to be retrieved from disk.

process 1 first sends the commands to the device controller and then process 2. After which they go sleeping, waiting for the data they requested to arrive.

But say the device supports native command queuing. And say it finishes retrieving the data for process 2 before process 1's data. The device issues an interrupt.
Interrupt handler saves data in buffer and "wakes up all sleeping processes".

But doesn't this mean process 1 will get the wrong data because the data saved in buffer is meant for process 2?
 
Old 09-04-2011, 06:25 PM   #4
onebuck
Moderator
 
Registered: Jan 2005
Location: Summer Midwest USA, Central Illinois, Winter Central Florida
Distribution: Slackware®
Posts: 13,565
Blog Entries: 34

Rep: Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738
Hi,

I believe the authors simple explanation by example answers your questions. Plus the definitive second paragraph should be valid answer to your queries.;
Quote:
Interrupt servicing can be compared to a programmer's job. The programmer opens a mailbox and does his routine programming work. When new mail arrives, he is interrupted by a beep or by some other notification at the corner of the screen. Immediately, he saves the program and switches over to the mailbox. He then reads the mail, sends an acknowledgement and resumes his earlier work. A detailed reply listing the steps he has taken is sent later.


Similarly, when a CPU executes a process, a device can send an interrupt to the CPU regarding some task, for example, data is ready for transfer. When an interrupt comes, the CPU instantly saves the current value of the program counter in the kernel mode stack and executes the corresponding interrupt service routine (ISR). An ISR is a function situated in the kernel that determines the nature of the interrupt and performs whatever actions are needed, such as moving a block of data from hard disk to main memory. After executing the ISR, the CPU resumes the earlier process and executes.
Device driver definition below;

Quote:

A device driver is a software module in the kernel that waits for requests from the application program. Whenever an application wants to read data from a device, the corresponding device driver is invoked immediately, and the respective device is open for reading. If the system is waiting for slow hardware, it cannot do any useful job. One of the prime aims of kernel developers is to utilize system resources effectively. To avoid waiting for data from the hardware, the kernel gives this job to the device controller and resumes the stopped process. When reading completes, the device notifies the CPU through an interrupt. The processor then executes the corresponding ISR.
Be sure to read the other sections to build towards full understanding;
http://www.linuxjournal.com/article/6946?page=0,1
http://www.linuxjournal.com/article/6946?page=0,2
http://www.linuxjournal.com/article/6946?page=0,3
 
Old 09-05-2011, 12:20 AM   #5
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180
Let me try ...

As you know, when anything interesting happens on the hardware, an interrupt is generated. The incoming interrupt is first fielded by a hardware "programmable interrupt controller" chip on the motherboard, because there are far fewer interrupt-lines available on the CPU than there might be devices that need to cause interrupts, and because fairly sophisticated timing and multiplexing needs. The PIC boils all of that down to the mere 16-or-so interrupt lines that are available. It asserts the interrupt. "Phone #8 is now ringing."

When an interrupt happens and the CPU accepts it, control is passed to a first-level interrupt handler, which collects status from the device, quashes the interrupt so that it doesn't keep happening, and then it schedules the second-level interrupt processing routine to happen "real soon now." Control then passes to the schedule() routine in the kernel, whose job it is to decide what needs to happen next. The odds are pretty good that the scheduler will decide to "park" the current task and switch control to some other now-more-important diversion. But it may or it may not decide that "the second-level routine" is the most urgent thing to be done right now. (And I am going to completely omit discussion of "multiple CPUs!")

Eventually, the second-level interrupt handler does win the lottery, and its routine gets dispatched. It is either in this routine or in the first-level routine that the determination is made as to exactly what device caused the interrupt and exactly what response(s) now need to be taken. If a disk I/O handler concludes by whatever means that a "normal I/O completion" status has been signaled by "device #0132," it might move the incoming data as necessary and inform the scheduler that "process #123456 is now eligible to run again." (Therefore, at some unforeseen time in the reasonably-near future, some CPU's going to get to run process #123456 whereas until now it would have chosen to ignore it.)

The hardware interrupt, itself, is merely "the phone is ringing," and, "by the way, it's a party line." The scheduler is the both the switchboard-operator and the commander-in-chief with regards to what each of the CPUs will ultimately do next. Except during the very brief instants when first-level interrupt handlers may be running (and this only because the scheduler has deigned to enable the appropriate interrupts...), the scheduler is always the ultimate and exclusive decision-maker.

Last edited by sundialsvcs; 09-05-2011 at 12:27 AM.
 
Old 09-05-2011, 11:56 AM   #6
Marnix
LQ Newbie
 
Registered: Sep 2011
Posts: 3

Original Poster
Rep: Reputation: Disabled
Thanks for you try, but how does the handler know the process the data is for, is for process #123456? How does the handler know it must tell the kernel that his process can run again when the kernel sees fit?

process 1 requests sector 1 from hard drive
process 2 requests sector 2 from hard drive
both processes sleep.

hard drive first reads sector 2 and issues interrupt.

then please tell me how does the interrupt handler know for which process the data is intended? both processes are sleeping; their memory can be swapped to disk and not be available in main memory anymore...how do these few bytes of code in the interrupt handler know that the bytes in the device's register are meant for process 2 and not for process 1? the device can't tell that to the handler..the device just retrieves what it is asked to, it has no idea for which process it is meant...how does the handler know which process it must awake?

and remember: the article in the link above says the handler just awakes every process...so also process 1.....while the data retrieved is for process 2.

I cant explain my question more clear than this. For me it isnt obvious at all.
 
Old 09-05-2011, 08:58 PM   #7
onebuck
Moderator
 
Registered: Jan 2005
Location: Summer Midwest USA, Central Illinois, Winter Central Florida
Distribution: Slackware®
Posts: 13,565
Blog Entries: 34

Rep: Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738
Hi,

Quote:
Originally Posted by Marnix View Post
Thanks for you try, but how does the handler know the process the data is for, is for process #123456? How does the handler know it must tell the kernel that his process can run again when the kernel sees fit?

process 1 requests sector 1 from hard drive
process 2 requests sector 2 from hard drive
both processes sleep.

hard drive first reads sector 2 and issues interrupt.

then please tell me how does the interrupt handler know for which process the data is intended? both processes are sleeping; their memory can be swapped to disk and not be available in main memory anymore...how do these few bytes of code in the interrupt handler know that the bytes in the device's register are meant for process 2 and not for process 1? the device can't tell that to the handler..the device just retrieves what it is asked to, it has no idea for which process it is meant...how does the handler know which process it must awake?

and remember: the article in the link above says the handler just awakes every process...so also process 1.....while the data retrieved is for process 2.

I cant explain my question more clear than this. For me it isnt obvious at all.
You are failing to remember the program counter(PC) is pushed onto kernel mode stack and the ISR is executed. Interrupt will cause the PC to be pushed onto the stack until the interrupt is serviced. Then the PC is popped off the stack to allow interrupted program to continue or continue with another interrupted service/program. You are confusing the ISR with the device driver. Device driver is allowed to service via the ISR. Priority of the interrupt will dictate service via PIC. If you look at a basic PIC (peripheral interface controller) you would see each line for interrupt assignments for all controlled devices.

Kernel ISR will control the integration of which interrupt to service. Once that service is allowed then the device driver will control the device functionality or data control.

Plus do not confuse user space(User-space device drivers [LWN.net]) and kernel space (Making System Calls From Kernel Space).

I cannot see why the below definition is confusing you;
Quote:
excerpt from http://www.linuxjournal.com/article/6946?page=0,0
Until version 2.6, Linux had been non-preemptive, meaning that when a process is running in kernel mode, if any higher-priority process arrives in the ready-to-run queue, the lower-priority process cannot be preempted until it returns to user mode. But, an interrupt is allowed to divert CPU attention even though it is executing a process in kernel mode. This helps to improve the throughput of a system. When an interrupt occurs, the CPU suspends the current task and executes some other code, which responds to whatever event caused the interrupt.
Each device in a computer has a device controller, and it has a hardware pin that is used to assert when the device requires CPU service. This pin is attached to the corresponding interrupt pin in the CPU, which facilitates communication. The pin in the processor connected to the controller is called the interrupt request line. A CPU has several such pins so that many devices can be serviced by the processor. In a modern operating system, a programmable interrupt controller (PIC) is used to manage the IRQ lines between the processor and the various device controllers. The number of free IRQs in a system is restricted, but Linux has a mechanism to allow many pieces of hardware to share the same interrupts.
Linux Kernel Newbies will be of some help.

Last edited by onebuck; 09-06-2011 at 07:39 AM. Reason: typos
 
Old 11-29-2011, 01:39 AM   #8
needle_
LQ Newbie
 
Registered: Nov 2011
Posts: 8

Rep: Reputation: 0
Hi Marnix. It's a shame nobody is answering your very simple question, as I had the exact same question. I have not found any useful information to it on the internet after searching for half an hour.

The fact is, that hardware devices must be forced to respond synchronously/linearly/in-order as if they responded out of order, there would be no way for the kernel to know which interrupting data was for which process, unless the same process was ran the entire time io was being waited on, which it isn't, and at the same time, the data would be out of order.

There is no place to plainly state this to cure my mind. Although it obviously must be true, unless there was some message passing/p2p bus algorithm tagging the order of data, (which I did come across in my googling, as a patent request) though we know this is not the case for the average computer.

I hope someone else can confirm this.

Last edited by needle_; 11-29-2011 at 01:47 AM.
 
Old 11-29-2011, 07:43 AM   #9
onebuck
Moderator
 
Registered: Jan 2005
Location: Summer Midwest USA, Central Illinois, Winter Central Florida
Distribution: Slackware®
Posts: 13,565
Blog Entries: 34

Rep: Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738
Hi,
Welcome to LQ!
Quote:
Originally Posted by needle_ View Post
Hi Marnix. It's a shame nobody is answering your very simple question, as I had the exact same question. I have not found any useful information to it on the internet after searching for half an hour.
Maybe refine the search terms.
Quote:
Originally Posted by needle_ View Post
The fact is, that hardware devices must be forced to respond synchronously/linearly/in-order as if they responded out of order, there would be no way for the kernel to know which interrupting data was for which process, unless the same process was ran the entire time io was being waited on, which it isn't, and at the same time, the data would be out of order.
Not really! Interrupt handler is the core of device management.

Quote:
Originally Posted by needle_ View Post
There is no place to plainly state this to cure my mind. Although it obviously must be true, unless there was some message passing/p2p bus algorithm tagging the order of data, (which I did come across in my googling, as a patent request) though we know this is not the case for the average computer.

I hope someone else can confirm this.
Simple example. Without ISR or interrupts the 'average' computer would not function very well. Really useless instead of a useful tool. Service routines allow the processor to control data flow from the device for the interrupt;
Quote:
excerpt from Operating System;
Interrupt Interrupts are central to operating systems, as they provide an efficient way for the operating system to interact with and react to its environment. The alternative — having the operating system "watch" the various sources of input for events (polling) that require action — can be found in older systems with very small stacks (50 or 60 bytes) but are unusual in modern systems with large stacks. Interrupt-based programming is directly supported by most modern CPUs. Interrupts provide a computer with a way of automatically saving local register contexts, and running specific code in response to events. Even very basic computers support hardware interrupts, and allow the programmer to specify code which may be run when that event takes place.
When an interrupt is received, the computer's hardware automatically suspends whatever program is currently running, saves its status, and runs computer code previously associated with the interrupt; this is analogous to placing a bookmark in a book in response to a phone call. In modern operating systems, interrupts are handled by the operating system's kernel. Interrupts may come from either the computer's hardware or from the running program.
When a hardware device triggers an interrupt, the operating system's kernel decides how to deal with this event, generally by running some processing code. The amount of code being run depends on the priority of the interrupt (for example: a person usually responds to a smoke detector alarm before answering the phone). The processing of hardware interrupts is a task that is usually delegated to software called device driver, which may be either part of the operating system's kernel, part of another program, or both. Device drivers may then relay information to a running program by various means.
A program may also trigger an interrupt to the operating system. If a program wishes to access hardware for example, it may interrupt the operating system's kernel, which causes control to be passed back to the kernel. The kernel will then process the request. If a program wishes additional resources (or wishes to shed resources) such as memory, it will trigger an interrupt to get the kernel's attention.
Rather broad example but you can get the idea.
 
Old 11-29-2011, 08:24 AM   #10
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180Reputation: 3180
The explanation ought to be clear ... but here is a more-complete (also simplified) version, start to finish:
  1. The process makes an I/O request. This causes a request-block data structure to be assembled and placed on a queue for the software driver's attention. The process then sleeps on a semaphore that is part of that request object.
  2. The software driver selects pending I/O requests in an optimized order (to minimize disk seek-time, etc.) and starts the request.
  3. The hardware eventually sends an interrupt. The first-level interrupt handler quickly schedules the second-level one. The dispatcher eventually selects it and runs it.
  4. The second-level handler gathers the final completion status of the request, associating it with whatever request-block is known to be "the currently active request," and it signals the semaphore upon which the user-level process is sleeping, thereby making that process runnable again.
  5. At some point in the future, the dispatcher (on some CPU...) selects that process and the process resumes.

You can visualize the device-driver as being a sort of "kernel level process" of its own, responsible for accepting a queue of I/O requests and servicing them. It executes at a high priority because, once a request has been completed, the driver needs to "quickly get the paperwork out of the way" so that it can promptly start the next request. Everything in the entire procedure is asynchronous, such that it is never possible to predict exactly which CPU will be doing what, or exactly when.

Interrupts, as a hardware mechanism, are exactly like "a phone call on a party line." Most of the time you don't sit "staring at the phone waiting for it to do something." Instead, you react when it rings. (And if "the phone is ringing off the wall," you might not react immediately or in any particular sequence.) The analogy is quite apt, and the common-sense purpose for it is apparent.

Last edited by sundialsvcs; 11-29-2011 at 08:28 AM.
 
Old 11-30-2011, 07:26 PM   #11
needle_
LQ Newbie
 
Registered: Nov 2011
Posts: 8

Rep: Reputation: 0
Meh

You are all beating entirely around the bush, answering every generic question about an interrupt handler OTHER than exactly what was asked. Let's rephrase this question, and ask how the kernel knows about the order of incomming data, received from a device, and that will answer the man's question.

For processes to run while "interrupts are pending" (or rather, a request is waiting to be responded to, from a device), then for any computer to know which ORDER any incomming data associated with an intterupt would be in, it would have to specify its order somehow, or it would have to be responded to in the fashion and order in which the kernel and processor requested data.

This is the point and the question. Either an everyday computer bus specifies the order and association of data, or it is just assumed to be in order based on protocol. There is no other way. Therefor I leave it to someone that is trying to actually help, and not cause more confusion, to answer the question with a simple YES, implying most everyday pc devices, if not all, respond in the order in which they where requested for IO, or NO, meaning most bus architectures have some associated data in their response or on some other bus, which specifies the order of the data associated w/ an interrupt.

As said, there is no other way. Apples are not oranges. It is a yes or no answer.

Last edited by needle_; 11-30-2011 at 07:33 PM.
 
Old 11-30-2011, 08:05 PM   #12
needle_
LQ Newbie
 
Registered: Nov 2011
Posts: 8

Rep: Reputation: 0
And here also.

Also, the scenario can be outlined as below:

The kernel, with use of the processor, triggers an interrupt for the disk controller, and sends its request to read a byte, or what have you, at a specific offset.

The kernel triggers another interrupt, and sends another request, to read another byte, at another offset, before it has had a response to the previous request.

The disk controller either has to send back the two bytes, or what have you size data, in the same order in which it was requested, or it must specify, somehow, the order it is responding, and which byte pertains to which request.

If neither of those happened, the kernel would be left unaware of which bytes where for which requests, and it might enqueue the wrong bytes, in the wrong order, or pertaining to the wrong requests. Which to a userland application would quite likely result in it receiving the entirely wrong byte for a read.

The order is the answer to the question. Although to further the question, we're requesting to know which methodology is used in the everyday system.

Thanks =]

For historical sense, the writer has summed up the proceeding conversations to be roughly equivalent of the following aggregate conversation:

needle: "Hi, what's your birthday? Mine is November 29th, 1986"
onebuck: "NO NEEDLE! WRONG! George Walker Bush (born July 6, 1946) is an American politician who served as the 43rd President of the United States, from 2001 to 2009."
sundialsvcs: "I like bananas, with whipped cream. Let's all celebrate my birthday early."

The writer assumes zero responsibility.

needle_
 
Old 11-30-2011, 08:37 PM   #13
needle_
LQ Newbie
 
Registered: Nov 2011
Posts: 8

Rep: Reputation: 0
The order of data

"
A bus protocol is an agreed set of rules for transmitting information between two or
more devices over a bus. The protocol determines the following:
• the type and order of data being sent;
• how the sending device indicates that it has finished sending the information;
• the data compression method used, if any;
• how the receiving device acknowledges successful reception of the information;
• how arbitration is performed to resolve contenti
"

http://www.ee.ic.ac.uk/pcheung/teach...20handouts.pdf

=]
 
Old 11-30-2011, 09:25 PM   #14
needle_
LQ Newbie
 
Registered: Nov 2011
Posts: 8

Rep: Reputation: 0
And more information.

"A transaction over a particular bus normally involves a requesting device (the "requester") and a responding device (the "target"). The requester requests the transfer of data or a completion signal from a target in the system. The requesttypically includes a number of control bits indicating the type of request and an address of the desired data or device. The target, in turn, responds to the transaction by sending a completion signal along with any data if necessary. With the presenceof various devices acting as requesters and targets in the system, bus protocols often include the ability to handle multiple transactions among multiple devices concurrently. One example of such a bus is the pipelined bus which allows requests byvarious requesters to be pending (i.e., unfulfilled) over the bus at the same time. The incorporation of separate data and address buses makes this possible. In a pipelined transaction, a requester sends a request on the address bus, and a targetreturns a reply on the data bus. Multiple requesters may send multiple requests over the address bus, and multiple targets may respond in the same order of the requests over the data bus. In a special pipelined bus, commonly referred to as the splittransaction bus, the order of the responses does not have to occur in the same order as their corresponding requests. Each transaction is tagged so that the requester and the target keep track of the status of the transaction. This characteristicpermits maximum utilization of the pipelined bus by effectively increasing bus bandwidth. This advantage, however, is obtained at a cost of experiencing a higher latency than when a request is held during the pendency of a transaction."

This is exactly what I said, they either respond in the same order, or they are somehow marked or "tagged" (as this text puts it).

And by the way, this comes from lectures of the following patent:

http://www.patentgenius.com/patent/6223238.html

Which is "Method of peer-to-peer mastering over a computer bus"

As this is a patent from 2001, we can assume that most devices traditionally respond in-order and are not part of a futuristic peer-to-peer system =]

Although, it would still be nice as a confirmation, to know which the majority of typical system use these days.

Furthering the answer to this thread. I have found on wikipedia that pci-e IS a split transaction bus and allows communication out-of-order:

"Transaction layer
PCI Express implements split transactions (transactions with request and response separated by time), allowing the link to carry other traffic while the target device gathers data for the response."

Which means, in pci-e data must be tagged for order, somehow.

Here is another case of split-transaction where they say the 'latter-id' will see that the memory response is for it.

"split-transaction bus
A split-transaction bus means that when a CPU places a memory request on the bus, that CPU then immediately releases the bus, so that other entities can use the bus while the memory request is pending. When the memory request is complete, the memory module involved will then acquire the bus, place the result on the bus (the read value in the case of a read request, an acknowledgment in the case of a write request), and also place on the bus the ID number of the CPU that had made the request. The latter ID will see that the memory’s response is for it.

This rather clear and simple explanation of a split-transaction bus is takes from "Introduction to Discrete-Event Simulation and the SimPy Language" by Norm Matloff (http://heather.cs.ucdavis.edu/~matloff/156/PLN)."

http://code.google.com/p/hatch/wiki/SplitTransaction ; although they use memory in this example, it can clearly be expanded to apply to another bus and device, especially in the case of memory mapped io =]

Also there is a bit more information in the chapter entitled "Transaction Ordering" in this book on the pci-e bus:

http://www.mindshare.com/files/ebook...chitecture.pdf

"Because the Producer/Consumer model depends on strong ordering, when the following conditions are met native PCI Express devices support this model without additional ordering rules"

That noted, pci legacy uses the "Producer/Consumer" model which is good old fashion in-order data being sent and received.

And on that note, the device obviously has to comply with the bus.

Thanks for your time, and I hope this answers everyone's question =]

needle_

[Edit] They know "which process an interrupt is for", not by the interrupt alone, although by the order of the data. If the kernel keeps track of the order, it can obviously keep track of to which queue, and furthermore, which process, the data belongs.

Last edited by needle_; 11-30-2011 at 09:44 PM.
 
Old 11-30-2011, 09:44 PM   #15
onebuck
Moderator
 
Registered: Jan 2005
Location: Summer Midwest USA, Central Illinois, Winter Central Florida
Distribution: Slackware®
Posts: 13,565
Blog Entries: 34

Rep: Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738Reputation: 2738
Hi,

Quote:
Originally Posted by needle_ View Post
You are all beating entirely around the bush, answering every generic question about an interrupt handler OTHER than exactly what was asked. Let's rephrase this question, and ask how the kernel knows about the order of incomming data, received from a device, and that will answer the man's question.

For processes to run while "interrupts are pending" (or rather, a request is waiting to be responded to, from a device), then for any computer to know which ORDER any incomming data associated with an intterupt would be in, it would have to specify its order somehow, or it would have to be responded to in the fashion and order in which the kernel and processor requested data.

This is the point and the question. Either an everyday computer bus specifies the order and association of data, or it is just assumed to be in order based on protocol. There is no other way. Therefor I leave it to someone that is trying to actually help, and not cause more confusion, to answer the question with a simple YES, implying most everyday pc devices, if not all, respond in the order in which they where requested for IO, or NO, meaning most bus architectures have some associated data in their response or on some other bus, which specifies the order of the data associated w/ an interrupt.

As said, there is no other way. Apples are not oranges. It is a yes or no answer.
Quote:
Hi Marnix. It's a shame nobody is answering your very simple question, as I had the exact same question. I have not found any useful information to it on the internet after searching for half an hour.
No one is beating around the bush! Hopefully the OP can discern your definition(s) by relation to the simpler representations.

BTW, Thanks for the 'PDF' which I'm sure is the result of your 1 1/2 hour search. The OP can use it along with the other information to hopefully get the idea of interrupts and how to service interrupts. Please provide the links to the information that you have quoted. It seems to come from the patent office.

[mod response]
There is no reason for snide sarcasm either. No one deserved your attempts at being cute. Everyone here is attempting to aid the OP. Simpler is sometimes easier to understand then present in depth at a later time when the OP responds back or as you did by reference information that may or may not be understood.

Please remove the 'aggregate conversation' example in #12 as it is not constructive nor necessary.
[mod response end]
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Kernel panic: killing interrupt handler! In interrupt handler - not syncing. divyashree Programming 26 05-15-2010 01:27 PM
How to send a msg to a process from an interrupt handler btklee Linux - Kernel 5 12-05-2008 10:21 AM
control is not going to interrupt handler when interrupt comes in serial driver sateeshalla Linux - Kernel 1 05-04-2006 09:43 AM
<0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing mrb Linux - Newbie 2 01-09-2005 09:47 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 09:16 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration