MESSAGE
DATE | 2015-02-04 |
FROM | Ruben Safir
|
SUBJECT | Subject: [LIU Comp Sci] (fwd) Re: Operating System Design
|
From owner-learn-outgoing-at-mrbrklyn.com Wed Feb 4 13:23:13 2015 Return-Path: X-Original-To: archive-at-mrbrklyn.com Delivered-To: archive-at-mrbrklyn.com Received: by mrbrklyn.com (Postfix) id 5AA2516115E; Wed, 4 Feb 2015 13:23:13 -0500 (EST) Delivered-To: learn-outgoing-at-mrbrklyn.com Received: by mrbrklyn.com (Postfix, from userid 28) id 4B50916116C; Wed, 4 Feb 2015 13:23:13 -0500 (EST) Delivered-To: learn-at-nylxs.com Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mrbrklyn.com (Postfix) with ESMTP id 8822416115E for ; Wed, 4 Feb 2015 13:23:12 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mailbackend.panix.com (Postfix) with ESMTP id 7AD3D13088 for ; Wed, 4 Feb 2015 13:23:12 -0500 (EST) Received: by panix2.panix.com (Postfix, from userid 20529) id 736F733CC5; Wed, 4 Feb 2015 13:23:12 -0500 (EST) From: Ruben Safir To: learn-at-nylxs.com Subject: [LIU Comp Sci] (fwd) Re: Operating System Design User-Agent: tin/2.0.0-20110823 ("Ardenistiel") (UNIX) (NetBSD/6.1.5 (i386)) Message-Id: <20150204182312.736F733CC5-at-panix2.panix.com> Date: Wed, 4 Feb 2015 13:23:12 -0500 (EST) Sender: owner-learn-at-mrbrklyn.com Precedence: bulk Reply-To: learn-at-mrbrklyn.com
-- forwarded message -- Path: reader1.panix.com!panix!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!ottix-news.ottix.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!enother.net!enother.net!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx28.iad.POSTED!not-for-mail From: Lew Pitcher Subject: Re: Operating System Design Newsgroups: comp.os.linux.hardware References: Lines: 65 Organization: The Pitcher Digital Freehold MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-ID: X-Complaints-To: abuse-at-UsenetServer.com NNTP-Posting-Date: Thu, 29 Jan 2015 22:38:22 UTC Date: Thu, 29 Jan 2015 17:38:21 -0500 X-Received-Bytes: 3288 X-Received-Body-CRC: 1262158883 Xref: panix comp.os.linux.hardware:364725
On Thursday January 29 2015 17:11, in comp.os.linux.hardware, "ruben safir" wrote:
> I'm wondering if anyone has a background in operating system design. > I'm taking a class is OS's and the text is > > OPERATING > SYSTEM > CONCEPTS > ABRAHAM SILBERSCHATZ
Don't know the book, so my remarks will have to be somewhat generic.
> 9th edition, and it says something that is puzzling me > > > > "Interrupts are an important part of a computer architecture. Each > computer design has its own interrupt mechanism, but several functions > are common. The interrupt must transfer control to the appropriate > interrupt service routine. The straightforward method for handling this > transfer would be to invoke a generic routine to examine the interrupt > information. The routine, in turn, would call the interrupt-specific > handler. However, interrupts must be handled quickly" > > " Since only a predefined number of interrupts is possible, a table of > pointers to interrupt routines can be used instead*** to provide the > necessary speed. The interrupt routine is called indirectly through the > table, with no intermediate routine needed. Generally, the table of > pointers is stored in low memory (the first hundred or so locations). > These locations hold the addresses of the interrupt service routines for > the various devices. This array, or interrupt vector, of addresses is > then indexed by a unique device number, given with the interrupt > request, to provide the address of the interrupt service routine for > the interrupting device. Operating systems as different as Windows and > UNIX dispatch interrupts in this manner." > > > *** Instead of what?
Certain hardware interrupts cause an execution branch to a specific location. Typically, the hardware will provide some identifying information available through an I/O call, and the logic branched to must then poll each eligible device for that information. Once the device has been identified and the information extracted, the logic can then process the interrupt condition.
Certain software interrupts also can cause an execution branch to a specific location. Typically, the software interrupt code will provide some identifying information available through inspection of the memory pointed to by interrupt program-counter. Once this information has been extracted, the logic can then process the interrupt condition.
Both of these types of interrupt expect to execute logic at a specific location, hardwired into the interrupt mechanism.
[snip]
HTH -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
-- end of forwarded message --
|
|