Questions about Minix - Minix

This is a discussion on Questions about Minix - Minix ; Hello, I tried Minix 3 yesterday and installed it. I have some questions regarding my short experience. - Is it possible to have the text/mode terminal emulator work in a more natural way without reprogramming tty? For example, I would ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

Thread: Questions about Minix

  1. Questions about Minix

    Hello,

    I tried Minix 3 yesterday and installed it. I have some questions regarding
    my short experience.

    - Is it possible to have the text/mode terminal emulator work in a more
    natural way without reprogramming tty? For example, I would like the Home
    and the End keys to work, and the Delete key to delete de character that
    lies under the cursor (and pull the others to the left).

    - While running X, is it possible to return to text mode without exiting X?
    I mean, in Linux and *BSD we do this just by pressing Ctrl+Alt+Fx, but in
    Minix this doesn't seem to work. Or is this caused by bad configuration of
    the server? Or both (Minix does not support the mechanism used by X to go
    back to text mode while still living)?

    - Given that, in part(8), "You can move all over the place with the arrow
    keys, change values, and make a mess of your partition table real quick.",
    is there any reason for it still being included, instead of some other
    partition table editor?

    Thanks,
    JJ


  2. Re: Questions about Minix

    Jo??o Jer??nimo wrote:
    > Hello,


    > - Given that, in part(8), "You can move all over the place with the arrow
    > keys, change values, and make a mess of your partition table real quick.",
    > is there any reason for it still being included, instead of some other
    > partition table editor?


    Yes there is. It works (if you know what you're doing), and it runs on
    Minix. AFAIK no other partition editor has been ported to Minix. However,
    if you don't trust Minix part (or yourself), you can always look around
    for a Linux live CD with a partition editor bundled into the software,
    it's bound to be around somwehere. See
    http://www.minix3.org/doc/partitions.html for some pointers on where to
    look.

    Regards,

    Jens


    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  3. Re: Questions about Minix

    J.F. de Smit escreveu:

    > Jo??o Jer??nimo wrote:
    >> Hello,

    >
    >> - Given that, in part(8), "You can move all over the place with the
    >> arrow
    >> keys, change values, and make a mess of your partition table real
    >> quick.", is there any reason for it still being included, instead of some
    >> other partition table editor?

    >
    > Yes there is. It works (if you know what you're doing), and it runs on
    > Minix.


    Yes, I know what I'm doing because I have (some) experience dealing with
    partitions.
    But it's true that the interface is a bit tricky to work with, and pretty
    easy to make a mistake.

    > AFAIK no other partition editor has been ported to Minix. However,
    > if you don't trust Minix part (or yourself), you can always look around
    > for a Linux live CD with a partition editor bundled into the software,
    > it's bound to be around somwehere.


    Ok, ok. I just wondered why, because an OS like Minix needs to have *some*
    degree of self-sufficience for configuring hardware (here, I consider
    editing the partition table as "hardware configuration") and installing the
    system.

    --
    Jo茫o Jer贸nimo


  4. Re: Questions about Minix

    On Wed, 13 Aug 2008, Jo鉶 Jer髇imo wrote:

    > Hello,
    >
    > I tried Minix 3 yesterday and installed it. I have some questions regarding
    > my short experience.
    >
    > - Is it possible to have the text/mode terminal emulator work in a more
    > natural way without reprogramming tty? [trim]


    > - While running X, is it possible to return to text mode without exiting X?
    > I mean, in Linux and *BSD we do this just by pressing Ctrl+Alt+Fx, but in
    > Minix this doesn't seem to work. [trim]


    I do not have Minix installed, but I have been following this ng out of
    somne interest. My understanding is that Minix is not supposed to be
    all things to all men. It is not supposed to be Unix or Linux. It is
    not supposed to do everything that those operating systems can. It is
    supposed to be a simple operating system, reliable and safe. For
    example, I work part time for one of the largest retail bookstore
    chains in the United States. We use computerized handheld scanners
    that use, of all things, a version of DOS (ROM-DOS)!!! I have the
    impression that, apart from its educational value, Minix is intended to
    be used for safe and reliable applications such as this, not to run the
    whole world.

    --
    Paul Bartlett

  5. Re: Questions about Minix

    Paul Bartlett wrote:

    > My understanding is that Minix is not supposed to be
    > all things to all men.


    No OS is supposed to be that kind of thing, although some get pretty close
    to that stage.

    > It is not supposed to be Unix or Linux.


    Of course not.

    > It is not supposed to do everything that those operating systems can.
    > It is supposed to be a simple operating system, reliable and safe.


    Of course not.

    > For example, I work part time for one of the largest retail bookstore
    > chains in the United States. We use computerized handheld scanners
    > that use, of all things, a version of DOS (ROM-DOS)!!! I have the
    > impression that, apart from its educational value, Minix is intended to
    > be used for safe and reliable applications such as this, not to run the
    > whole world.


    Now, what does this have to do with my question?

    JJ

  6. Re: Questions about Minix

    Jo??o Jer??nimo wrote:
    >> AFAIK no other partition editor has been ported to Minix. However,
    >> if you don't trust Minix part (or yourself), you can always look around
    >> for a Linux live CD with a partition editor bundled into the software,
    >> it's bound to be around somwehere.


    > Ok, ok. I just wondered why, because an OS like Minix needs to have *some*
    > degree of self-sufficience for configuring hardware (here, I consider
    > editing the partition table as "hardware configuration") and installing the
    > system.


    And so it does. It's not the easiest program to use, true, but it's a
    powerful tool. Powerful tools usually have the power to break stuff as
    well as fix stuff. And there's just no substitute for the experience of
    rewriting the partition table on a running system (as I did once). It's a
    very educational experience...

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  7. Re: Questions about Minix

    On Thu, 14 Aug 2008, Jo鉶 Jer髇imo wrote:

    > Paul Bartlett wrote:
    >
    >> My understanding is that Minix is not supposed to be
    >> all things to all men.

    >
    > No OS is supposed to be that kind of thing, although some get pretty close
    > to that stage.
    >
    >> [trim]


    >> For example, I work part time for one of the largest retail bookstore
    >> chains in the United States. We use computerized handheld scanners
    >> that use, of all things, a version of DOS (ROM-DOS)!!! I have the
    >> impression that, apart from its educational value, Minix is intended to
    >> be used for safe and reliable applications such as this, not to run the
    >> whole world.

    >
    > Now, what does this have to do with my question?


    My point is that your question may not be directly answerable within
    the original design features of Minix. Perhaps Minix was never
    intended to be able to run every graphical user interface (X, Gnome,
    KDE, ICE, whatever) under the sun, because its design doals were
    simple, perhaps including only a simple text user interface.

    --
    Paul Bartlett

  8. Re: Questions about Minix

    J.F. de Smit escreveu:

    > And so it does. It's not the easiest program to use, true, but it's a
    > powerful tool. Powerful tools usually have the power to break stuff as
    > well as fix stuff. And there's just no substitute for the experience of
    > rewriting the partition table on a running system (as I did once). It's a
    > very educational experience...


    Yes, I know (in fact, it's not much less powerful than most
    partition-editors).
    But it's interface is also a bit confusing at first (even to people who are
    used to work with disk partitions).

    Please, my original intent was not to get a flame war for free. I was only
    asking if there was any special reason or it was just because it works, and
    no one has to date bothered writing another one. :-)

    --
    Jo茫o Jer贸nimo


  9. Re: Questions about Minix

    Paul Bartlett escreveu:

    >>> For example, I work part time for one of the largest retail bookstore
    >>> chains in the United States. We use computerized handheld scanners
    >>> that use, of all things, a version of DOS (ROM-DOS)!!! I have the
    >>> impression that, apart from its educational value, Minix is intended to
    >>> be used for safe and reliable applications such as this, not to run the
    >>> whole world.

    >>
    >> Now, what does this have to do with my question?

    >
    > My point is that your question may not be directly answerable within
    > the original design features of Minix. Perhaps Minix was never
    > intended to be able to run every graphical user interface (X, Gnome,
    > KDE, ICE, whatever) under the sun, because its design doals were
    > simple, perhaps including only a simple text user interface.


    Of course not. Originally, Minix was mainly target at operating system
    classes in univercities.
    However, now it /even/ runs X windows, isn't this wonderful?
    Afaik, paging is currently being implemented, even though it may be
    considered unnecessary for the initial Minix's goals.

    Apart from that, I was *only* asking a question. I *do* respect AST's goals,
    and understand that Minix isn't intended to have, at least in it's "main"
    development branch, all the fancy features of a full-blown operating
    system.

    --
    Jo茫o Jer贸nimo

    "Computer are composed of software, hardware, and other stuff terminated
    in "ware", like firmware, tupperware, (...)" - by JJ.


  10. Re: Questions about Minix

    Paul Bartlett escreveu:

    > (X, Gnome, KDE, ICE, whatever)


    Another note: I'm not interested in runing KDE nor Gnome (well, I would if
    it was supported, but that's not the point here).

    --
    Jo茫o Jer贸nimo

    "Computer are composed of software, hardware, and other stuff terminated
    in "ware", like firmware, tupperware, (...)" - by JJ.

  11. Re: Questions about Minix

    Jo??o Jer??nimo wrote:
    > Of course not. Originally, Minix was mainly target at operating system
    > classes in univercities.
    > However, now it /even/ runs X windows, isn't this wonderful?
    > Afaik, paging is currently being implemented, even though it may be
    > considered unnecessary for the initial Minix's goals.


    Perhaps not, but it would make stuff a lot easier to use (especially X,
    allocating each component the memory it needs can be a real pain).

    > Apart from that, I was *only* asking a question. I *do* respect AST's goals,
    > and understand that Minix isn't intended to have, at least in it's "main"
    > development branch, all the fancy features of a full-blown operating
    > system.


    Well, questions tend to invite answers Don't worry, we're nice people,
    we simply get to the point a bit fast sometimes, without the nice
    introductions.

    The thing is, Minix is really growing at the moment, as well as settling
    into its new, third version design. With this growth come some growth
    problems, which may lead to unexpected situations. There's some great
    software out there (like Apache, PHP, libxslt), but getting X to work can
    be a real pain. Not everything is as polished as you might expect it.

    Oh, and the most likely answer to any "why is Minix lacking tool/feature here>" question is: nobody has implemented it yet. So, if you
    would like a fancy partition editor, a packet snifffer, a code cleaner,
    more file system support, you name it: port it and you'll make all of us
    happy.

    Kind regards,

    Jens


    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  12. Re: Questions about Minix

    J.F. de Smit wrote:
    > Jo茫o Jer贸nimo wrote:
    >> Of course not. Originally, Minix was mainly target at operating system
    >> classes in univercities.
    >> However, now it /even/ runs X windows, isn't this wonderful?
    >> Afaik, paging is currently being implemented, even though it may be
    >> considered unnecessary for the initial Minix's goals.

    >
    > Perhaps not, but it would make stuff a lot easier to use (especially X,
    > allocating each component the memory it needs can be a real pain).


    Yes. As I have read, Minix puts both the code and data segments in the same
    chunck of memory. This real makes stuff very "static", because the stack
    grows downwards, which means you couldn't just expand (and move arround if
    necessary) the segment when the application demands more heap than was
    initially expected (also, due to the sbrk system call spec, you can't just
    split the data segment in two parts allocating the rest beyond the
    stack)...
    Spliting the stack from the heap is also a non-solution, because C compilers
    are typically designed to expect a "flat" address space, at least from the
    point of view of the application (i.e. the app only sees one segment). In
    particular, they expect to be able to access the stack with registers that
    are not ESP/EBP, so if DS refered to a different chunk of memory than SS,
    segment overrides would have to be used, and additionally the compiler
    would have to decide where to use them and where not to use.

    Overall, it's better to use paging. After all, 64-bit Long Mode (like a
    bunch of alternative architectures) just doesn't support segmentation.

    > Well, questions tend to invite answers Don't worry, we're nice people,
    > we simply get to the point a bit fast sometimes, without the nice
    > introductions.


    No problem. I'm used to it. :-)

    > The thing is, Minix is really growing at the moment, as well as settling
    > into its new, third version design. With this growth come some growth
    > problems, which may lead to unexpected situations. There's some great
    > software out there (like Apache, PHP, libxslt), but getting X to work can
    > be a real pain. Not everything is as polished as you might expect it.


    Ok. I understand that OS development is composed of different stages, and
    stuff take time to get working right.

    > Oh, and the most likely answer to any "why is Minix lacking > tool/feature here>" question is: nobody has implemented it yet. So, if you
    > would like a fancy partition editor, a packet snifffer, a code cleaner,
    > more file system support, you name it: port it and you'll make all of us
    > happy.


    Thanks. That's what I wanted to read. :-)
    Unfortunatily, I'm very very unstable. And my interest usually vanishes in
    one week or two.
    But if I come with something useful that runs on Minix, now I know I will be
    welcome.

    --
    Jo茫o Jer贸nimo

    "Computer are composed of software, hardware, and other stuff terminated
    in "ware", like firmware, tupperware, (...)" ' by JJ

  13. Re: Questions about Minix

    Jo??o Jer??nimo wrote:
    > J.F. de Smit wrote:
    >> Perhaps not, but it would make stuff a lot easier to use (especially X,
    >> allocating each component the memory it needs can be a real pain).


    > Yes. As I have read, Minix puts both the code and data segments in the same
    > chunck of memory. This real makes stuff very "static", because the stack
    > grows downwards, which means you couldn't just expand (and move arround if
    > necessary) the segment when the application demands more heap than was
    > initially expected (also, due to the sbrk system call spec, you can't just
    > split the data segment in two parts allocating the rest beyond the
    > stack)...


    Your first statement isn't exactly correct and also doesn't seem related
    to what you say next, but you got the majority of it right. Minix actually
    _splits_ the code and data segments by default and assigns them different
    segments. This has several consequences:

    - address 0 (generally reserved for the NULL pointer) is actually a valid
    address in the data segment, because the data segment contains only data
    and no text. In situations where code and data share the same segment,
    address 0 always contains code and should never be accessed (not even by
    icky-icky self-modifying code). However, it is common sense to still
    regard 0 as an invalid memory address because you need _something_ to
    signal it and it costs you only 1 byte of usable memory

    - remote code execution through stack overflow is a lot harder (if not
    impossible) to accomplish, because the kernel forbids writing to a code
    segment, and the CPU only fetches opcode from the code segment (and not
    the data segment). Putting code on the stack and then overwriting a
    return address will get you erratic behaviour at best, but more likely a
    segfault (because the data+stack segment is much larger than the code
    segment and stack addresses are at the top of said segment, so a stack
    address as PC is probably invalid).

    - multiple instances of the same program can share a code segment. This
    saves memory, memory transfers and counters fragmentation issues possibly
    caused by using large amounts of small segments.

    On the other hand, what you said about the stack and data areas is true:
    they share the same segment, and it is fixed. There is no way to prevent a
    stack from growing into the heap (only a possibility of detecting it while
    context switching) and there is no way to give an application more memory
    than it was assigned at process creation time. This last thing especially
    causes the common "Not enough core" error message when running programs
    that (sometimes) require lots of memory.

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  14. Re: Questions about Minix

    J.F. de Smit wrote:
    > Jo茫o Jer贸nimo wrote:
    >> Yes. As I have read, Minix puts both the code and data segments in the
    >> same chunck of memory. This real makes stuff very "static", because the
    >> stack grows downwards, which means you couldn't just expand (and move
    >> arround if necessary) the segment when the application demands more heap
    >> than was initially expected (also, due to the sbrk system call spec, you
    >> can't just split the data segment in two parts allocating the rest beyond
    >> the stack)...

    >
    > Your first statement isn't exactly correct and also doesn't seem related
    > to what you say next, but you got the majority of it right. Minix actually
    > _splits_ the code and data segments by default and assigns them different
    > segments.


    I think I got to that conclusion that .text shared the same memory chunk
    as .(ro)data somewhat intuitively.
    But then I should have released that Minix would discard the majority of the
    benefits of using segmentation if it used that scheme.

    > - remote code execution through stack overflow is a lot harder (if not
    > impossible) to accomplish, because the kernel forbids writing to a code
    > segment, and the CPU only fetches opcode from the code segment (and not
    > the data segment). Putting code on the stack and then overwriting a
    > return address will get you erratic behaviour at best, but more likely a
    > segfault (because the data+stack segment is much larger than the code
    > segment and stack addresses are at the top of said segment, so a stack
    > address as PC is probably invalid).


    Ok. That's one of the benefits of segmentation, after all.
    OTOH, paging-based operating systems are now discovering the NX bit, that
    promises to accomplish the same goal. If they granted an user-mode code
    segment to processes from the beginning, and a data segment that did not
    start at 0, the same goal could be accomplished.

    > - multiple instances of the same program can share a code segment. This
    > saves memory, memory transfers and counters fragmentation issues possibly
    > caused by using large amounts of small segments.


    This needs copy-on-write techniques. Unless this "instances" are threads of
    the same process.

    > On the other hand, what you said about the stack and data areas is true:
    > they share the same segment, and it is fixed. There is no way to prevent a
    > stack from growing into the heap (only a possibility of detecting it while
    > context switching)


    An expand-down segment descriptor could be used to control stack growth.

    --
    Jo茫o Jer贸nimo

    "Computer are composed of software, hardware, and other stuff terminated
    in "ware", like firmware, tupperware, (...)" ' by JJ

  15. Re: Questions about Minix

    In article you wrote:
    > J.F. de Smit wrote:
    >> Joo Jernimo wrote:

    > I think I got to that conclusion that .text shared the same memory chunk
    > as .(ro)data somewhat intuitively.
    > But then I should have released that Minix would discard the majority of the
    > benefits of using segmentation if it used that scheme.


    I believe the original reason to use segmentation was simply to benefit
    from the MMU to protect processes from messing up eachother's memory
    areas, and nothing more. the "separate I&D" functionality is a new feature
    of Minix 3 if I'm correct.

    > Ok. That's one of the benefits of segmentation, after all.
    > OTOH, paging-based operating systems are now discovering the NX bit, that
    > promises to accomplish the same goal. If they granted an user-mode code
    > segment to processes from the beginning, and a data segment that did not
    > start at 0, the same goal could be accomplished.


    Correct, but this requires paging support from the kernel (not available
    yet) and more fine-grained (and thus more complex) memory management (at
    the page level instead of at the segment level). I'm not saying it's a bad
    idea (it sounds like a good one actually), I'm just trying to figure out
    why Minix doesn't support it (yet). Going out on a limb for a bit, it
    might even be possible to support both models by tinkering a bit with the
    kernel and writing a second, more complex process manager. That way, the
    demanding people can have a paged, NX-supporting, fancy-featured system
    while students and starting hobbyists can have a working system simple
    enough for them to tinker with.

    >> - multiple instances of the same program can share a code segment. This
    >> saves memory, memory transfers and counters fragmentation issues possibly
    >> caused by using large amounts of small segments.


    > This needs copy-on-write techniques. Unless this "instances" are threads of
    > the same process.


    Sorry about the confusion, but I distinguish a "program" (a description on
    disk) from a "process" (an instance of said program, being executed). What
    I meant is that several processes running the same program (e.g. 4 bash
    shells) can share the same .text segment, as it is guaranteed to be
    immutable. You won't need copy-on-write techniques, because it's
    prohibited by the kernel and MMU to write to the .text segment.

    >> On the other hand, what you said about the stack and data areas is true:
    >> they share the same segment, and it is fixed. There is no way to prevent a
    >> stack from growing into the heap (only a possibility of detecting it while
    >> context switching)


    > An expand-down segment descriptor could be used to control stack growth.


    True, but this would limit your stack size to some predetermined value,
    meaning things go haywire as soon as you run out of stack space, even if
    you still have plenty of heap left. By combining heap and stack into one
    segment, things will run smoothly until the stack runs into the uppermost
    allocated part of the heap. OTOH, the current approach has a race
    condition: if the stack runs into the heap, but shrinks back to a legal
    size before the kernel gets called due to a trap or interrupt, it is
    impossible to tell that the process has destroyed its own heap, leading to
    incorrect behaviour.

    All in all, I think it is safe to say that we're all _eagerly_ awaiting
    the new memory model

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  16. Re: Questions about Minix

    J.F. de Smit escreveu:
    > I believe the original reason to use segmentation was simply to benefit
    > from the MMU to protect processes from messing up eachother's memory
    > areas, and nothing more. the "separate I&D" functionality is a new feature
    > of Minix 3 if I'm correct.


    I thought people did not consider segmentation to be performed by the MMU.
    Paging is, but segmentation is not.

    > Going out on a limb for a bit, it might even be possible to support both
    > models by tinkering a bit with the kernel and writing a second, more
    > complex process manager. That way, the demanding people can have a paged,
    > NX-supporting, fancy-featured system while students and starting hobbyists
    > can have a working system simple enough for them to tinker with.


    IMHO paging support is much easy to understand than segmentation support (at
    least the allocation part).
    Segmentation requires allocating a chunk of contiguous bytes in a best-fit
    or a first-fit fashion, while paging only requires some sort of page frame
    allocator using a stack or a bitmap (but there's no "first-fit"
    nor "best-fit" trick in it).

    Of course you still need to allocate chunks of contiguous memory, but only
    at a higher level; in user mode and at kernel level if you need dynamic
    memory allocation in kernel (I heard from Tanennbaum himself that Minix
    does not use dynamic memory in kernel land (because it uses one static
    buffer per process to support IPC, and suspends the sending process when
    the receiving buffer is full), but I may have misunderstood).

    >>> - multiple instances of the same program can share a code segment. This
    >>> saves memory, memory transfers and counters fragmentation issues
    >>> possibly caused by using large amounts of small segments.

    >
    >> This needs copy-on-write techniques. Unless this "instances" are threads
    >> of the same process.

    >
    > (...)
    > immutable. You won't need copy-on-write techniques, because it's
    > prohibited by the kernel and MMU to write to the .text segment.


    Sorry. I read "data segment".
    Yes, the code segment can be shared. Now I understand this wouldn't be
    possible without spliting the code and data segments.

    >>> On the other hand, what you said about the stack and data areas is true:
    >>> they share the same segment, and it is fixed. There is no way to prevent
    >>> a stack from growing into the heap (only a possibility of detecting it
    >>> while context switching)

    >> An expand-down segment descriptor could be used to control stack growth.

    >
    > True, but this would limit your stack size to some predetermined value,
    > meaning things go haywire as soon as you run out of stack space, even if
    > you still have plenty of heap left.


    No if you catched the "overflow" using the Stack Fault.
    A Stack Fault to be handled in Ring 0 causes a stack switch (unless the
    processor is already in ring 0, but that's not the case), so it's safe.
    The kernel could then expand the stack segment or kill the process if it
    would run into the heap. This could be done because the library has to call
    the kernel (sbrk) every time it expands the heap, so the stack fault
    handler could know if there was any space left.

    > By combining heap and stack into one
    > segment, things will run smoothly until the stack runs into the uppermost
    > allocated part of the heap. OTOH, the current approach has a race
    > condition: if the stack runs into the heap, but shrinks back to a legal
    > size before the kernel gets called due to a trap or interrupt, it is
    > impossible to tell that the process has destroyed its own heap, leading to
    > incorrect behaviour.


    An expand-down stack segment could avoid this particular problem.

    --
    Jo茫o Jer贸nimo

    "Computer are composed of software, hardware, and other stuff terminated
    in "ware", like firmware, tupperware, (...)" - by JJ.

  17. Re: Questions about Minix

    J.F. de Smit escreveu:

    >>> - multiple instances of the same program can share a code segment. This
    >>> saves memory, memory transfers and counters fragmentation issues
    >>> possibly caused by using large amounts of small segments.

    >
    >> This needs copy-on-write techniques. Unless this "instances" are threads
    >> of the same process.

    >
    > Sorry about the confusion, but I distinguish a "program" (a description on
    > disk) from a "process" (an instance of said program, being executed). What
    > I meant is that several processes running the same program (e.g. 4 bash
    > shells) can share the same .text segment, as it is guaranteed to be
    > immutable. You won't need copy-on-write techniques, because it's
    > prohibited by the kernel and MMU to write to the .text segment.


    Something now came to my mind.
    Suppose I'm a (small, in terms of .text) process. I have a high chmem. So
    high that I don't fit twice in memory. However, I fit once.
    Now, I want to execute another program, that fits in the remaining free
    memory. To do this, I need to do fork()+execve(). Does the kernel tries to
    clone my data segment after the fork(), thus disabling me from executing
    another (small) program?

    --
    Jo茫o Jer贸nimo

    "Computer are composed of software, hardware, and other stuff terminated
    in "ware", like firmware, tupperware, (...)" - by JJ.

  18. Re: Questions about Minix

    > Something now came to my mind.
    > Suppose I'm a (small, in terms of .text) process. I have a high
    > chmem. So high that I don't fit twice in memory. However, I fit once.
    > Now, I want to execute another program, that fits in the remaining
    > free memory. To do this, I need to do fork()+execve(). Does the
    > kernel tries to clone my data segment after the fork(), thus
    > disabling me from executing another (small) program?


    Correct. Fixing this indeed requires copy-on-write which in turn
    requires paging, which will probably take substantial time to make it
    to a release.

    --
    With kind regards,
    Erik van der Kouwe

  19. Re: Questions about Minix

    Jo??o Jer??nimo wrote:
    > J.F. de Smit escreveu:
    >> I believe the original reason to use segmentation was simply to benefit
    >> from the MMU to protect processes from messing up eachother's memory
    >> areas, and nothing more. the "separate I&D" functionality is a new feature
    >> of Minix 3 if I'm correct.


    > I thought people did not consider segmentation to be performed by the MMU.
    > Paging is, but segmentation is not.


    You're right, I was confusing the MMU and the CPU's segment registers for
    a moment there. What I meant to say is that without separate I&D, each
    MINIX process has exactly one segment assigned to it, with the only
    function of segmentation in this case being memory protection and
    virtual-to-physical address translation.

    >> Going out on a limb for a bit, it might even be possible to support both
    >> models by tinkering a bit with the kernel and writing a second, more
    >> complex process manager. That way, the demanding people can have a paged,
    >> NX-supporting, fancy-featured system while students and starting hobbyists
    >> can have a working system simple enough for them to tinker with.


    > IMHO paging support is much easy to understand than segmentation support (at
    > least the allocation part).
    > Segmentation requires allocating a chunk of contiguous bytes in a best-fit
    > or a first-fit fashion, while paging only requires some sort of page frame
    > allocator using a stack or a bitmap (but there's no "first-fit"
    > nor "best-fit" trick in it).


    I don't know about that. I think you can only really appreciate some of
    the benefits of paging once you understand the fragmentation problem
    caused by only using segmentation. I also feel that the implementation of
    paging, with the GDT, LDTs, automatic switches and whatnot is a bit more
    complex than segmentation.

    > Of course you still need to allocate chunks of contiguous memory, but only
    > at a higher level; in user mode and at kernel level if you need dynamic
    > memory allocation in kernel (I heard from Tanennbaum himself that Minix
    > does not use dynamic memory in kernel land (because it uses one static
    > buffer per process to support IPC, and suspends the sending process when
    > the receiving buffer is full), but I may have misunderstood).


    You're correct, the kernel is designed to not need dynamic memory
    allocation. I believe there _is_ a malloc() function in kernel space, but
    the goal is to never use it. In most IPC calls, the sending process is
    blocked until the receiving process has sent a reply back, i.e. fully
    synchronous operation. This means that the sending process is only resumed
    after the receiving process has called receive(), done something and then
    calls send() to return a reply.

    > No if you catched the "overflow" using the Stack Fault.
    > A Stack Fault to be handled in Ring 0 causes a stack switch (unless the
    > processor is already in ring 0, but that's not the case), so it's safe.
    > The kernel could then expand the stack segment or kill the process if it
    > would run into the heap. This could be done because the library has to call
    > the kernel (sbrk) every time it expands the heap, so the stack fault
    > handler could know if there was any space left.


    This sounds like a workable solution.

    >> By combining heap and stack into one
    >> segment, things will run smoothly until the stack runs into the uppermost
    >> allocated part of the heap. OTOH, the current approach has a race
    >> condition: if the stack runs into the heap, but shrinks back to a legal
    >> size before the kernel gets called due to a trap or interrupt, it is
    >> impossible to tell that the process has destroyed its own heap, leading to
    >> incorrect behaviour.


    > An expand-down stack segment could avoid this particular problem.


    True, but it does require a bunch more administration, possibly adjusting
    the stack's descriptor on an sbrk call when a process wants to grow the
    heap into the space reserved for the stack. But, it moght be worth the
    trouble.

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  20. Re: Questions about Minix

    "Erik van der Kouwe" few.vu.nl> escreveu:
    >> Something now came to my mind.
    >> Suppose I'm a (small, in terms of .text) process. I have a high
    >> chmem. So high that I don't fit twice in memory. However, I fit once.
    >> Now, I want to execute another program, that fits in the remaining
    >> free memory. To do this, I need to do fork()+execve(). Does the
    >> kernel tries to clone my data segment after the fork(), thus
    >> disabling me from executing another (small) program?

    >
    > Correct. Fixing this indeed requires copy-on-write which in turn
    > requires paging, which will probably take substantial time to make it
    > to a release.


    One could still implement copy-on-write using segmentation.
    Only, instead of duplicating the pages as they are written, the data segment
    needed to be duplicated all at once.
    The only problem would be if the parent process wrote something in the
    memory immediately after the fork().
    (now, thinking about that, it's pretty likely that the parent does that)

    --
    Jo茫o Jer贸nimo

    "Computer are composed of software, hardware, and other stuff terminated
    in "ware", like firmware, tupperware, (...)" - by JJ.

+ Reply to Thread
Page 1 of 2 1 2 LastLast