tss, memory and figures - Minix

This is a discussion on tss, memory and figures - Minix ; hi i've noticed there are many other guys like me on the board who are having trouble understanding the task switching and interrupt mechanism, so at least i don't feel so stupid any more. i know the answers to all ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: tss, memory and figures

  1. tss, memory and figures

    hi
    i've noticed there are many other guys like me on the board who are
    having trouble understanding the task switching and interrupt
    mechanism, so at least i don't feel so stupid any more.
    i know the answers to all my questions lie in the code but, honestly, i
    think the book would be a much greater help if it included more figures
    illustrating what is described in words rather than hundreds of pages
    of code (does any of you actually browse back and forth in the book
    while reading it? i usually sit in front of the computer with my book;
    this makes it a lot easier to find the right place in the code and to
    go back and forth)

    anyway, i want to post some fundamental questions which have been
    keeping my mind busy for some time:

    on page 129 there is a figure showing the layout of the boot image in
    memory.
    what is not shown, is where all the processes segments are located. how
    is segment memory laid out. imagine 2 processes: a and b. you have many
    different choices how segments could be laid out, e.g.:

    1 2
    ------------------------
    start code a code a
    .. data a code b
    .. stack a data a
    .. code b data b
    .. data b stack a
    end stack b stackb

    well these are just two of several possible layouts. another related
    question is how big each segment is. also, x86 processors have more
    than just 3 segment registers (es, fs, gs)...what role do these other
    segment registers play? where do they point?

    the second point has to do yet again with the tss. minix uses only 1
    tss, right? so, as far as i understand now, minix uses the proc struct
    to save and restore information about processes and their registers,
    and when a task switch occurs, the information and registers of the old
    task is saved from the tss into the proc struct and then the tss is
    filled with the registers of the new process...i dont know whether im
    right here but if i am, this sounds like a lot of work and
    overhead..why not have different tss's in memory and just switch
    between them (which would make all the copying unnecessary)
    also, if there is only 1 tss at all in a minix system, then what about
    the back link field in a tss? obviously it cant point to the previously
    executed process since it is the only tss there exists



    another point i dont understand is the following statement on page 165
    (top of page): ..., the KERNEL process (also identified as HARDWARE) is
    never considered ready, never runs as and ordinary process, and thus
    has no need of a stack pointer.

    first question: if it never runs, why have it?

    second question: no need of a stack pointer? if it never runs, is there
    anything it DOES need? i wouldn't be able to come up with anything
    reasonable



    the last point, for now :-), is the following: on page 169, the
    interrupt mechanism is described. it is said (3rd line): "The effect is
    that the new stack created by an interrupt always starts at the end of
    the stackframe_s structure within the process table entry of the
    interrupted process."
    That's another example of a difficultly understood description due to a
    lack of illustrations: If the new stack starts at the end of the
    stackframe_s structure in the process table entry, then you would bump
    into the other information that comes after stackframe_s within the
    struct proc, namely p_ldt_sel:

    struct proc {
    05517 struct stackframe_s p_reg; /* process' registers saved in
    stack frame */
    05518 reg_t p_ldt_sel; /* selector in gdt with ldt base
    and limit */
    05519 struct segdesc_s p_ldt[2+NR_REMOTE_SEGS]; /* CS, DS and remote
    segments */
    05520
    05521 proc_nr_t p_nr; /* number of this process (for
    fast access) */
    05522 struct priv *p_priv; /* system privileges structure
    */
    05523 char p_rts_flags; /* SENDING, RECEIVING, etc. */
    05524
    05525 char p_priority; /* current scheduling priority
    */
    05526 char p_max_priority; /* maximum scheduling priority
    */
    05527 char p_ticks_left; /* number of scheduling ticks
    left */
    05528 char p_quantum_size; /* quantum size in ticks */
    05529
    05530 struct mem_map p_memmap[NR_LOCAL_SEGS]; /* memory map (T, D,
    S) */
    05531
    05532 clock_t p_user_time; /* user time in ticks */
    05533 clock_t p_sys_time; /* sys time in ticks */
    05534
    05535 struct proc *p_nextready; /* pointer to next ready process
    */
    05536 struct proc *p_caller_q; /* head of list of procs wishing
    to send */
    05537 struct proc *p_q_link; /* link to next proc wishing to
    send */
    05538 message *p_messbuf; /* pointer to passed message
    buffer */
    05539 proc_nr_t p_getfrom; /* from whom does process want
    to receive? */
    05540 proc_nr_t p_sendto; /* to whom does process want to
    send? */
    05541
    05542 sigset_t p_pending; /* bit map for pending kernel
    signals */
    05543
    05544 char p_name[P_NAME_LEN]; /* name of the process,
    including \0 */
    05545 };

    I still think osdi is a good book, particularly the os-independent
    parts at the start of each chapter, but again, when it comes to
    describing the minix-specific details, more illustrations would be
    helpful for understanding whats actually going on behind the scenes.
    maybe some of the more experts on this board would like to come up with
    figures showing whats going on here. that would be nice!

    thanx,

    martin


  2. Re: tss, memory and figures

    sancho1980 wrote:

    > i know the answers to all my questions lie in the code but, honestly, i
    > think the book would be a much greater help if it included more figures


    I agree, pictures help. There are more of them in the 3rd edition than
    the 2nd. But, although a picture may be worth 1000 words, a picture
    also takes up a lot of space, and the pictures would be hard to
    understand without words. This is by way of saying that the book is
    quite large now and for anything added something else would need to be
    deleted to keep it from growing to an unmanageable size. That said, I
    save comments like yours and will think about this when (if?) the time
    comes to start working on a new edition.

    I will try to answer some of your questions below...

    > on page 129 there is a figure showing the layout of the boot image in
    > memory. what is not shown, is where all the processes segments are
    > located. how is segment memory laid out[?]...


    The figure you refer to (Figure 2-31, it could be on a different page
    in a translated edition) shows how the processes that are part of the
    system are laid out overall. Each individual process has an internal
    structure in memory which is illustrated in figure 4-31 in the Memory
    Management chapter. This structure is true for all of the system
    processes named in Figure 2-31, but some differences are possible for
    user processes, as I will explain further down.

    > another related question is how big each segment is. also, x86
    > processors have more than just 3 segment registers (es, fs, gs)...
    > what role do these other segment registers play?


    The additional registers do not have to be managed by the operating
    system. Some may be used by object code generated by the compiler, but
    whatever code is needed to initialize them will be generated by the
    compiler. The ES register can be used at assembly language level to
    copy data between segments, but Minix processes do not access multiple
    data segments and this feature of the CPU architecture is not needed.

    For an individual process the internal memory layout is described in
    Figure 4-33. There are two models of register use. The common I and D
    (instruction and data) model is described mostly for historical
    reasons, programs with this structure are not generated by default with
    the Minix compiler. In this model the segment registers for the code,
    data, and stack segments point to the same physical address. This model
    was used with early versions of Minix for the 8088 processor, which did
    not have segment descriptors that reserved a fixed amount of space for
    a segment; as far as the CPU is concerned such segments can use the
    full 64 K of memory that can be addressed. The size of a segment using
    this model is a variable within the OS code, and an attempt to access
    an address outside a segment boundary cannot be detected by the CPU.
    The stack size is determined by the initial address loaded into the
    stack pointer, which grows downward from that address toward virtual
    address 0, which is equivalent to the physical address pointed to by
    the stack segment register shifted left 4 bits.

    The memory model in current use uses separate I and D space. In
    protected mode the registers considered segment registers in the 8088
    (CS, DS, SS, etc) are pointers to descriptors. These are data
    structures that define the start of a segment in physical memory and
    the size of the segment, as well as a number of other properties. See
    Figure 4-26. The CPU can trap attempts to access memory locations
    outside of a defined segment. Moreover, the segments for code and data
    do not overlap, although they are contiguous, as shown in Figure 4-33.
    The data and stack segment descriptors describe the same area of
    memory, but the stack grows down from higher addresses and the data
    area grows up from lower addresses. The CPU cannot detect a collision,
    but an OS table keeps track of the current upper limit of memory
    available for data and the current downward extent of the stack.

    More than one copy of a user process can be in memory at once (think of
    two shells for two users logged on at different terminals). Since the
    instruction section is read-only, two processes can share a common copy
    of the instructions. This is shared text, shown in Figure 4-34. This
    is the exception I mentioned in the answer to your first question. Only
    one copy of a system process is needed (why would you have two copies
    of a driver?) and so this never occurs with any process named in Figure
    2-31

    > the second point has to do yet again with the tss. ...


    I am not going to try to answer your TSS question now, maybe someone
    else can help here. I think it's a good question, but I did not write
    the code and, although it may have been explained to me once, I don't
    recall why it is done as it is done.

    > ..., the KERNEL process (also identified as HARDWARE) is
    > never considered ready, never runs as and ordinary process, and thus
    > has no need of a stack pointer.
    >
    > first question: if it never runs, why have it?


    It never runs like an ordinary process, it is the part of the system
    that starts ordinary processes running, stops them when they block or
    are interrupted or use up their time quantum, and decides which process
    to run next. But kernel code executes and kernel code and data and
    stack occupy memory, so they have to be accounted for. For bookkeeping
    purposes the time used by the kernel in support of a particular process
    is considered time used by that process.

    > second question: no need of a stack pointer?


    The kernel runs at a higher priority than anything else, it has a stack
    pointer but the kernel registers do not get stored in the way that
    registers for processes that are subservient to the kernel are stored.

    > ... If the new stack starts at the end of the stackframe_s structure
    > in the process table entry, then you would bump into the other
    > information that comes after stackframe_s within the struct proc,
    > namely p_ldt_sel:


    No, remember the stack grows downward. So as information is pushed onto
    the stack it fills in space reserved within the stackframe -- the first
    register pushed goes in just below p_ldt_sel, the next goes below that,
    etc.

    I hope this is helpful. One of the problems in describing an OS is that
    many things are going on simultaneously, but a book is written
    line-by-line and chapter-by-chapter, so sometimes skipping around is
    needed to gain a full understanding of something that is not fully
    described the first time it is encountered, as, for instance memory
    use.

    Good luck with your studies,

    - Al


  3. Re: tss, memory and figures

    sancho1980 wrote:

    > i know the answers to all my questions lie in the code but, honestly, i
    > think the book would be a much greater help if it included more figures


    I agree, pictures help. There are more of them in the 3rd edition than
    the 2nd. But, although a picture may be worth 1000 words, a picture
    also takes up a lot of space, and the pictures would be hard to
    understand without words. This is by way of saying that the book is
    quite large now and for anything added something else would need to be
    deleted to keep it from growing to an unmanageable size. That said, I
    save comments like yours and will think about this when (if?) the time
    comes to start working on a new edition.

    I will try to answer some of your questions below...

    > on page 129 there is a figure showing the layout of the boot image in
    > memory. what is not shown, is where all the processes segments are
    > located. how is segment memory laid out[?]...


    The figure you refer to (Figure 2-31, it could be on a different page
    in a translated edition) shows how the processes that are part of the
    system are laid out overall. Each individual process has an internal
    structure in memory which is illustrated in figure 4-31 in the Memory
    Management chapter. This structure is true for all of the system
    processes named in Figure 2-31, but some differences are possible for
    user processes, as I will explain further down.

    > another related question is how big each segment is. also, x86
    > processors have more than just 3 segment registers (es, fs, gs)...
    > what role do these other segment registers play?


    The additional registers do not have to be managed by the operating
    system. Some may be used by object code generated by the compiler, but
    whatever code is needed to initialize them will be generated by the
    compiler. The ES register can be used at assembly language level to
    copy data between segments, but Minix processes do not access multiple
    data segments and this feature of the CPU architecture is not needed.

    For an individual process the internal memory layout is described in
    Figure 4-33. There are two models of register use. The common I and D
    (instruction and data) model is described mostly for historical
    reasons, programs with this structure are not generated by default with
    the Minix compiler. In this model the segment registers for the code,
    data, and stack segments point to the same physical address. This model
    was used with early versions of Minix for the 8088 processor, which did
    not have segment descriptors that reserved a fixed amount of space for
    a segment; as far as the CPU is concerned such segments can use the
    full 64 K of memory that can be addressed. The size of a segment using
    this model is a variable within the OS code, and an attempt to access
    an address outside a segment boundary cannot be detected by the CPU.
    The stack size is determined by the initial address loaded into the
    stack pointer, which grows downward from that address toward virtual
    address 0, which is equivalent to the physical address pointed to by
    the stack segment register shifted left 4 bits.

    The memory model in current use uses separate I and D space. In
    protected mode the registers considered segment registers in the 8088
    (CS, DS, SS, etc) are pointers to descriptors. These are data
    structures that define the start of a segment in physical memory and
    the size of the segment, as well as a number of other properties. See
    Figure 4-26. The CPU can trap attempts to access memory locations
    outside of a defined segment. Moreover, the segments for code and data
    do not overlap, although they are contiguous, as shown in Figure 4-33.
    The data and stack segment descriptors describe the same area of
    memory, but the stack grows down from higher addresses and the data
    area grows up from lower addresses. The CPU cannot detect a collision,
    but an OS table keeps track of the current upper limit of memory
    available for data and the current downward extent of the stack.

    More than one copy of a user process can be in memory at once (think of
    two shells for two users logged on at different terminals). Since the
    instruction section is read-only, two processes can share a common copy
    of the instructions. This is shared text, shown in Figure 4-34. This
    is the exception I mentioned in the answer to your first question. Only
    one copy of a system process is needed (why would you have two copies
    of a driver?) and so this never occurs with any process named in Figure
    2-31

    > the second point has to do yet again with the tss. ...


    I am not going to try to answer your TSS question now, maybe someone
    else can help here. I think it's a good question, but I did not write
    the code and, although it may have been explained to me once, I don't
    recall why it is done as it is done.

    > ..., the KERNEL process (also identified as HARDWARE) is
    > never considered ready, never runs as and ordinary process, and thus
    > has no need of a stack pointer.
    >
    > first question: if it never runs, why have it?


    It never runs like an ordinary process, it is the part of the system
    that starts ordinary processes running, stops them when they block or
    are interrupted or use up their time quantum, and decides which process
    to run next. But kernel code executes and kernel code and data and
    stack occupy memory, so they have to be accounted for. For bookkeeping
    purposes the time used by the kernel in support of a particular process
    is considered time used by that process.

    > second question: no need of a stack pointer?


    The kernel runs at a higher priority than anything else, it has a stack
    pointer but the kernel registers do not get stored in the way that
    registers for processes that are subservient to the kernel are stored.

    > ... If the new stack starts at the end of the stackframe_s structure
    > in the process table entry, then you would bump into the other
    > information that comes after stackframe_s within the struct proc,
    > namely p_ldt_sel:


    No, remember the stack grows downward. So as information is pushed onto
    the stack it fills in space reserved within the stackframe -- the first
    register pushed goes in just below p_ldt_sel, the next goes below that,
    etc.

    I hope this is helpful. One of the problems in describing an OS is that
    many things are going on simultaneously, but a book is written
    line-by-line and chapter-by-chapter, so sometimes skipping around is
    needed to gain a full understanding of something that is not fully
    described the first time it is encountered, as, for instance memory
    use.

    Good luck with your studies,

    - Al


  4. Re: tss, memory and figures

    sancho1980 wrote:

    > i know the answers to all my questions lie in the code but, honestly, i
    > think the book would be a much greater help if it included more figures


    I agree, pictures help. There are more of them in the 3rd edition than
    the 2nd. But, although a picture may be worth 1000 words, a picture
    also takes up a lot of space, and the pictures would be hard to
    understand without words. This is by way of saying that the book is
    quite large now and for anything added something else would need to be
    deleted to keep it from growing to an unmanageable size. That said, I
    save comments like yours and will think about this when (if?) the time
    comes to start working on a new edition.

    I will try to answer some of your questions below...

    > on page 129 there is a figure showing the layout of the boot image in
    > memory. what is not shown, is where all the processes segments are
    > located. how is segment memory laid out[?]...


    The figure you refer to (Figure 2-31, it could be on a different page
    in a translated edition) shows how the processes that are part of the
    system are laid out overall. Each individual process has an internal
    structure in memory which is illustrated in figure 4-31 in the Memory
    Management chapter. This structure is true for all of the system
    processes named in Figure 2-31, but some differences are possible for
    user processes, as I will explain further down.

    > another related question is how big each segment is. also, x86
    > processors have more than just 3 segment registers (es, fs, gs)...
    > what role do these other segment registers play?


    The additional registers do not have to be managed by the operating
    system. Some may be used by object code generated by the compiler, but
    whatever code is needed to initialize them will be generated by the
    compiler. The ES register can be used at assembly language level to
    copy data between segments, but Minix processes do not access multiple
    data segments and this feature of the CPU architecture is not needed.

    For an individual process the internal memory layout is described in
    Figure 4-33. There are two models of register use. The common I and D
    (instruction and data) model is described mostly for historical
    reasons, programs with this structure are not generated by default with
    the Minix compiler. In this model the segment registers for the code,
    data, and stack segments point to the same physical address. This model
    was used with early versions of Minix for the 8088 processor, which did
    not have segment descriptors that reserved a fixed amount of space for
    a segment; as far as the CPU is concerned such segments can use the
    full 64 K of memory that can be addressed. The size of a segment using
    this model is a variable within the OS code, and an attempt to access
    an address outside a segment boundary cannot be detected by the CPU.
    The stack size is determined by the initial address loaded into the
    stack pointer, which grows downward from that address toward virtual
    address 0, which is equivalent to the physical address pointed to by
    the stack segment register shifted left 4 bits.

    The memory model in current use uses separate I and D space. In
    protected mode the registers considered segment registers in the 8088
    (CS, DS, SS, etc) are pointers to descriptors. These are data
    structures that define the start of a segment in physical memory and
    the size of the segment, as well as a number of other properties. See
    Figure 4-26. The CPU can trap attempts to access memory locations
    outside of a defined segment. Moreover, the segments for code and data
    do not overlap, although they are contiguous, as shown in Figure 4-33.
    The data and stack segment descriptors describe the same area of
    memory, but the stack grows down from higher addresses and the data
    area grows up from lower addresses. The CPU cannot detect a collision,
    but an OS table keeps track of the current upper limit of memory
    available for data and the current downward extent of the stack.

    More than one copy of a user process can be in memory at once (think of
    two shells for two users logged on at different terminals). Since the
    instruction section is read-only, two processes can share a common copy
    of the instructions. This is shared text, shown in Figure 4-34. This
    is the exception I mentioned in the answer to your first question. Only
    one copy of a system process is needed (why would you have two copies
    of a driver?) and so this never occurs with any process named in Figure
    2-31

    > the second point has to do yet again with the tss. ...


    I am not going to try to answer your TSS question now, maybe someone
    else can help here. I think it's a good question, but I did not write
    the code and, although it may have been explained to me once, I don't
    recall why it is done as it is done.

    > ..., the KERNEL process (also identified as HARDWARE) is
    > never considered ready, never runs as and ordinary process, and thus
    > has no need of a stack pointer.
    >
    > first question: if it never runs, why have it?


    It never runs like an ordinary process, it is the part of the system
    that starts ordinary processes running, stops them when they block or
    are interrupted or use up their time quantum, and decides which process
    to run next. But kernel code executes and kernel code and data and
    stack occupy memory, so they have to be accounted for. For bookkeeping
    purposes the time used by the kernel in support of a particular process
    is considered time used by that process.

    > second question: no need of a stack pointer?


    The kernel runs at a higher priority than anything else, it has a stack
    pointer but the kernel registers do not get stored in the way that
    registers for processes that are subservient to the kernel are stored.

    > ... If the new stack starts at the end of the stackframe_s structure
    > in the process table entry, then you would bump into the other
    > information that comes after stackframe_s within the struct proc,
    > namely p_ldt_sel:


    No, remember the stack grows downward. So as information is pushed onto
    the stack it fills in space reserved within the stackframe -- the first
    register pushed goes in just below p_ldt_sel, the next goes below that,
    etc.

    I hope this is helpful. One of the problems in describing an OS is that
    many things are going on simultaneously, but a book is written
    line-by-line and chapter-by-chapter, so sometimes skipping around is
    needed to gain a full understanding of something that is not fully
    described the first time it is encountered, as, for instance memory
    use.

    Good luck with your studies,

    - Al


  5. Re: tss, memory and figures

    In article <1166098201.470101.162490@80g2000cwy.googlegroups.c om>,
    sancho1980 wrote:
    >the second point has to do yet again with the tss. minix uses only 1
    >tss, right? so, as far as i understand now, minix uses the proc struct
    >to save and restore information about processes and their registers,
    >and when a task switch occurs, the information and registers of the old
    >task is saved from the tss into the proc struct and then the tss is
    >filled with the registers of the new process...i dont know whether im
    >right here but if i am, this sounds like a lot of work and
    >overhead..why not have different tss's in memory and just switch
    >between them (which would make all the copying unnecessary)
    >also, if there is only 1 tss at all in a minix system, then what about
    >the back link field in a tss? obviously it cant point to the previously
    >executed process since it is the only tss there exists


    The thing to remember is that as far as the processor is concerned,
    there is never any task switch. All parts in tss related to hardware
    task switches (such as the link field, but also the storage for the
    registers are unused).

    A tss is required to switch from level 3 to level 0 and back again.
    By playing clever tricks with the stack point field in the tss segment,
    it is possible to get the processor to save some of the registers
    in the process structure.


    --
    That was it. Done. The faulty Monk was turned out into the desert where it
    could believe what it liked, including the idea that it had been hard done
    by. It was allowed to keep its horse, since horses were so cheap to make.
    -- Douglas Adams in Dirk Gently's Holistic Detective Agency

  6. Re: tss, memory and figures


    Al Woodhull schrieb:

    > sancho1980 wrote:
    >
    > > i know the answers to all my questions lie in the code but, honestly, i
    > > think the book would be a much greater help if it included more figures

    >
    > I agree, pictures help. There are more of them in the 3rd edition than
    > the 2nd. But, although a picture may be worth 1000 words, a picture
    > also takes up a lot of space, and the pictures would be hard to
    > understand without words. This is by way of saying that the book is
    > quite large now and for anything added something else would need to be
    > deleted to keep it from growing to an unmanageable size. That said, I
    > save comments like yours and will think about this when (if?) the time
    > comes to start working on a new edition.
    >
    > I will try to answer some of your questions below...
    >
    > > on page 129 there is a figure showing the layout of the boot image in
    > > memory. what is not shown, is where all the processes segments are
    > > located. how is segment memory laid out[?]...

    >
    > The figure you refer to (Figure 2-31, it could be on a different page
    > in a translated edition) shows how the processes that are part of the
    > system are laid out overall. Each individual process has an internal
    > structure in memory which is illustrated in figure 4-31 in the Memory
    > Management chapter. This structure is true for all of the system
    > processes named in Figure 2-31, but some differences are possible for
    > user processes, as I will explain further down.
    >
    > > another related question is how big each segment is. also, x86
    > > processors have more than just 3 segment registers (es, fs, gs)...
    > > what role do these other segment registers play?

    >
    > The additional registers do not have to be managed by the operating
    > system. Some may be used by object code generated by the compiler, but
    > whatever code is needed to initialize them will be generated by the
    > compiler. The ES register can be used at assembly language level to
    > copy data between segments, but Minix processes do not access multiple
    > data segments and this feature of the CPU architecture is not needed.
    >
    > For an individual process the internal memory layout is described in
    > Figure 4-33. There are two models of register use. The common I and D
    > (instruction and data) model is described mostly for historical
    > reasons, programs with this structure are not generated by default with
    > the Minix compiler. In this model the segment registers for the code,
    > data, and stack segments point to the same physical address. This model
    > was used with early versions of Minix for the 8088 processor, which did
    > not have segment descriptors that reserved a fixed amount of space for
    > a segment; as far as the CPU is concerned such segments can use the
    > full 64 K of memory that can be addressed. The size of a segment using
    > this model is a variable within the OS code, and an attempt to access
    > an address outside a segment boundary cannot be detected by the CPU.
    > The stack size is determined by the initial address loaded into the
    > stack pointer, which grows downward from that address toward virtual
    > address 0, which is equivalent to the physical address pointed to by
    > the stack segment register shifted left 4 bits.
    >
    > The memory model in current use uses separate I and D space. In
    > protected mode the registers considered segment registers in the 8088
    > (CS, DS, SS, etc) are pointers to descriptors. These are data
    > structures that define the start of a segment in physical memory and
    > the size of the segment, as well as a number of other properties. See
    > Figure 4-26. The CPU can trap attempts to access memory locations
    > outside of a defined segment. Moreover, the segments for code and data
    > do not overlap, although they are contiguous, as shown in Figure 4-33.
    > The data and stack segment descriptors describe the same area of
    > memory, but the stack grows down from higher addresses and the data
    > area grows up from lower addresses. The CPU cannot detect a collision,
    > but an OS table keeps track of the current upper limit of memory
    > available for data and the current downward extent of the stack.
    >
    > More than one copy of a user process can be in memory at once (think of
    > two shells for two users logged on at different terminals). Since the
    > instruction section is read-only, two processes can share a common copy
    > of the instructions. This is shared text, shown in Figure 4-34. This
    > is the exception I mentioned in the answer to your first question. Only
    > one copy of a system process is needed (why would you have two copies
    > of a driver?) and so this never occurs with any process named in Figure
    > 2-31
    >
    > > the second point has to do yet again with the tss. ...

    >
    > I am not going to try to answer your TSS question now, maybe someone
    > else can help here. I think it's a good question, but I did not write
    > the code and, although it may have been explained to me once, I don't
    > recall why it is done as it is done.
    >
    > > ..., the KERNEL process (also identified as HARDWARE) is
    > > never considered ready, never runs as and ordinary process, and thus
    > > has no need of a stack pointer.
    > >
    > > first question: if it never runs, why have it?

    >
    > It never runs like an ordinary process, it is the part of the system
    > that starts ordinary processes running, stops them when they block or
    > are interrupted or use up their time quantum, and decides which process
    > to run next. But kernel code executes and kernel code and data and
    > stack occupy memory, so they have to be accounted for. For bookkeeping
    > purposes the time used by the kernel in support of a particular process
    > is considered time used by that process.
    >
    > > second question: no need of a stack pointer?

    >
    > The kernel runs at a higher priority than anything else, it has a stack
    > pointer but the kernel registers do not get stored in the way that
    > registers for processes that are subservient to the kernel are stored.
    >
    > > ... If the new stack starts at the end of the stackframe_s structure
    > > in the process table entry, then you would bump into the other
    > > information that comes after stackframe_s within the struct proc,
    > > namely p_ldt_sel:

    >
    > No, remember the stack grows downward. So as information is pushed onto
    > the stack it fills in space reserved within the stackframe -- the first
    > register pushed goes in just below p_ldt_sel, the next goes below that,
    > etc.
    >
    > I hope this is helpful. One of the problems in describing an OS is that
    > many things are going on simultaneously, but a book is written
    > line-by-line and chapter-by-chapter, so sometimes skipping around is
    > needed to gain a full understanding of something that is not fully
    > described the first time it is encountered, as, for instance memory
    > use.
    >
    > Good luck with your studies,
    >
    > - Al


    I think I'll have to read all this10 times and more before I understand
    what's going on.
    Has any of you managed to get a full grasp of the code just by reading
    the book (i.e. without any college class on it)...I'm curious...maybe I
    should start with yoga so I dont lose patience so quick...


+ Reply to Thread