Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #13507

Re: operating systems design

Show all headers | View raw

On 01/29/2015 05:29 PM, Rich wrote:
> ruben safir <ruben@mrbrklyn.com> 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
>> 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?  Just because you have a table of pointers to
>> routines doesn't change the need for a routine, a generic routine
>> perhaps, from accessing that table.
> 
> Instead of what was described in the first paragraph you quoted.
> 
> The first paragraph is stating that the simplest method is to have all
> interrupts call into a common routine.  Then that common routine has to
> figure out what called it, and perform the appropriate action
> (typically done by making another call into the actual subroutine that
> handles the specifics).
> 
> The "instead" in the second paragraph is removing the "generic, long
> list of 'if this then that'" tests which would make up the single
> generic routine, and instead replacing it with each "thing" which
> generates an interrupt telling the CPU: I am number X.  Then, knowing
> number X made the request, the cpu can directly call the specific
> subroutine necessary to handle the specifics.  No "middle man"
> necessary.
> 


Thank you.  I'm very ignorant about these things, so please pardon me if
I ask a follow up question with this regard.  I took an architecture
place last semester, and other than that, and my 20 some odd years of
tinkering, I don't have much of  formal education as to how this works.

The objective is to remove a routine that has a cascade of ifelses,
which is fine.  And you don't want the CPU to run a routine to figure
out who is call it.  How can the CPU know who calls it anyway, with or
without a routine?  It is only but getting specific information
transmitted to it on a line bus as an opcode that it can respond to an
instruction.  So if an interupt device sends a signal, the signal has to
identify who it is, regardless.  This is not something the hardware can
conjure up by itself.  And even an array of HW numbers in vector doesn't
prevent the need from having to search the array for the correct
hardware device interrupt routine to search for.  Additionally, you have
to make a back up of the current state, so that takes some routine code.

So how is it possible to eliminate that "middle man"?  No matter how the
interrupt routines are mapped as data in a system, you still need a
routine to process the requests?  How can it be eliminated?


Ruben

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

operating systems design ruben safir <ruben@mrbrklyn.com> - 2015-01-29 17:11 -0500
  Re: operating systems design Rich <rich@example.invalid> - 2015-01-29 22:29 +0000
    Re: operating systems design ruben safir <ruben@mrbrklyn.com> - 2015-01-30 08:19 -0500
      Re: operating systems design "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-01-30 09:01 -0500
      Re: operating systems design Robert Heller <heller@deepsoft.com> - 2015-01-30 08:07 -0600
        Re: operating systems design Jeroen Belleman <jeroen@nospam.please> - 2015-01-30 15:43 +0100
          Re: operating systems design Robert Heller <heller@deepsoft.com> - 2015-01-30 09:09 -0600
      Re: operating systems design Rich <rich@example.invalid> - 2015-01-30 15:21 +0000
        Re: operating systems design Robert Heller <heller@deepsoft.com> - 2015-01-30 11:27 -0600
          Re: operating systems design Rich <rich@example.invalid> - 2015-01-30 19:10 +0000
            Re: operating systems design Jean-David Beyer <jeandavid8@verizon.net> - 2015-02-02 08:29 -0500
              Re: operating systems design Rich <rich@example.invalid> - 2015-02-02 15:09 +0000
      Re: operating systems design The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 00:11 +0000
  Re: operating systems design Jeroen Belleman <jeroen@nospam.please> - 2015-01-30 09:28 +0100
  Re: operating systems design The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 00:08 +0000
    Re: operating systems design Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-02-03 20:52 +0000
      Re: operating systems design The Natural Philosopher <tnp@invalid.invalid> - 2015-02-03 21:06 +0000
      Re: operating systems design Rich <rich@example.invalid> - 2015-02-03 21:19 +0000

csiph-web