Info required on minix implementation status - Minix

This is a discussion on Info required on minix implementation status - Minix ; Hi, I was looking for what are the major areas to be concentrated upon, and have compiled a small list. Maybe we can add this in the todo list, and contributors can start off. Please let me know your comments: ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Info required on minix implementation status

  1. Info required on minix implementation status

    Hi,
    I was looking for what are the major areas to be concentrated upon, and
    have compiled a small list. Maybe we can add this in the todo list, and
    contributors can start off.
    Please let me know your comments:
    1. Virtual Memory implementation with Paging, PAE, etc: Where are we
    here? What do we want here? I mean are we going to support paging,
    swapping etc.?
    2. Virtual File system: Is it being implemented? Should we port it from
    Linux?
    3. X (and graphics framework): Do we follow the X methodology, or
    DirectFB etc? Both can be done, prioritising is required.
    4. Drivers: This is a big one. But need to find out what has already
    been done.
    5. Cross-compilation: Compiling minix and applications under Linux,
    FreeBSD etc. Is there any document, or t needs to be created?

    I am just posting this so that we can pinpoint where we can contribute.
    Please comment.
    Arindam Roy


  2. Re: Info required on minix implementation status

    In article <1158044484.055066.170840@b28g2000cwb.googlegroups. com>,
    Arindam Roy wrote:
    >Hi,
    >I was looking for what are the major areas to be concentrated upon, and
    >have compiled a small list. Maybe we can add this in the todo list, and
    >contributors can start off.


    There is a somewhat out of date 'Who is Doing What' page on www.minix3.org

    >Please let me know your comments:
    >1. Virtual Memory implementation with Paging, PAE, etc: Where are we
    >here? What do we want here? I mean are we going to support paging,
    >swapping etc.?


    VM has been assigned to Ben. Swapping is not part of the requirements
    (but I have a strong suspicion that a complete mmap implementation will
    give you swapping more or less for free).

    There is no design yet.

    >2. Virtual File system: Is it being implemented? Should we port it from
    >Linux?


    A student created a VFS implementation. This needs integration in the
    source tree and possibly cleaning up.

    In this context, we do need a subversion port, because CVS doesn't support
    moving files around. If anybody has some time left...

    >3. X (and graphics framework): Do we follow the X methodology, or
    >DirectFB etc? Both can be done, prioritising is required.


    X is just a port of the X.org sources.

    >4. Drivers: This is a big one. But need to find out what has already
    >been done.



    sort of lists the few drivers that we have. There is one exception, and
    that is the audio drivers in the audio-1.0.0 package.

    >5. Cross-compilation: Compiling minix and applications under Linux,
    >FreeBSD etc. Is there any document, or t needs to be created?


    There is no support for cross-compilation. Do you cross-compile
    FreeBSD under Linux?

    Cross-compiling requires a lot of addition effort in Makefiles, etc.
    It is much easier to just install vmware or qemu.

    >I am just posting this so that we can pinpoint where we can contribute.


    What would be nice is a detailed list of features required by popular
    software packages that are not currently in Minix 3. For example does
    a package like apache, samba, firefox, etc. require mmap, shared libraries,
    unix domain sockets, process groups (job control), threads (a complete
    thread safe C library), etc.


    --
    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

  3. Re: Info required on minix implementation status


    Arindam Roy ha escrito:

    > Hi,
    > I was looking for what are the major areas to be concentrated upon, and
    > have compiled a small list. Maybe we can add this in the todo list, and
    > contributors can start off.
    > Please let me know your comments:
    > 1. Virtual Memory implementation with Paging, PAE, etc: Where are we
    > here? What do we want here? I mean are we going to support paging,
    > swapping etc.?
    > 2. Virtual File system: Is it being implemented? Should we port it from
    > Linux?
    > 3. X (and graphics framework): Do we follow the X methodology, or
    > DirectFB etc? Both can be done, prioritising is required.
    > 4. Drivers: This is a big one. But need to find out what has already
    > been done.
    > 5. Cross-compilation: Compiling minix and applications under Linux,
    > FreeBSD etc. Is there any document, or t needs to be created?
    >
    > I am just posting this so that we can pinpoint where we can contribute.
    > Please comment.
    > Arindam Roy


    I would want add some features that I consider hight priority to
    implement:

    06. Porting the GNU libstdc++
    07. Implementing pthreads or some library to handle threading (for
    kernel threads, should be nice to implement something like the
    DragonFlyBSD light weight kernel threads [LWKT]).
    08. Subversion
    09. Support for shared libraries (it can be added after the
    paging/segmentation implementation, I think)
    10. On top of the libstdc++, a Qt port to support KDE should be nice
    too.


  4. Re: Info required on minix implementation status


    1. Virtual Memory implementation with Paging, PAE, etc: Where are we
    here? What do we want here? I mean are we going to support paging,
    swapping etc.?
    2. Virtual File system: Is it being implemented? Should we port it from
    Linux?
    3. X (and graphics framework): Do we follow the X methodology, or
    DirectFB etc? Both can be done, prioritising is required.
    4. Drivers: This is a big one. But need to find out what has already
    been done.
    5. Cross-compilation: Compiling minix and applications under Linux,
    FreeBSD etc. Is there any document, or t needs to be created?
    06. Porting the GNU libstdc++
    07. Implementing pthreads or some library to handle threading (for
    kernel threads, should be nice to implement something like the
    DragonFlyBSD light weight kernel threads [LWKT]).
    08. Subversion
    09. Support for shared libraries (it can be added after the
    paging/segmentation implementation, I think)
    10. On top of the libstdc++, a Qt port to support KDE should be nice
    too.
    11. Something like NetBSD pkgsrc.
    12. A common repository for all the ports (I dunno if this is already
    running)


  5. Re: Info required on minix implementation status


    Philip Homburg wrote:

    >>What would be nice is a detailed list of features required by popular
    >>software packages that are not currently in Minix 3. For example does
    >>a package like apache, samba, firefox, etc. require mmap, shared

    libraries,
    >>unix domain sockets, process groups (job control), threads (a complete
    >>thread safe C library), etc.


    This is a nice idea, exactly what I had on my mind lately: a detailed list
    that methodically describes Minix features in comparison with other major
    OSs. This would save much effort from any developer trying to gather
    independently all this info in order to proceed with porting a project to
    Minix. There are some previous attempts to guide the porting procedure in
    the bibliography for instance the dated "Porting UNIX Software" and the new
    one "UNIX to Linux(R) Porting: A Comprehensive Reference" that could be used
    as examples to start with.

    Christos



  6. Re: Info required on minix implementation status

    A side-thought, totally counter-productive, I know:

    Why do you concentrate on building another big fat OS?

    It will become a "me-too" OS not better or even worse than the other
    mini-micro-Linuxes around.

    For me Minix fills the somewhat empty niche for small systems that DOS has
    left behind many years ago.
    I know DOS is not multitasking, unstable and its filesystem is archaic. But
    imagine what it could have become: s.th. like Minix.






  7. Re: Info required on minix implementation status

    In article <450714d0$0$17407$9b4e6d93@newsspool2.arcor-online.net>,
    Andreas Kochenburger wrote:
    >A side-thought, totally counter-productive, I know:
    >
    >Why do you concentrate on building another big fat OS?


    There are not enough Minix 3 developers to turn it into a big fat OS.

    >For me Minix fills the somewhat empty niche for small systems that DOS has
    >left behind many years ago.
    >I know DOS is not multitasking, unstable and its filesystem is archaic. But
    >imagine what it could have become: s.th. like Minix.


    The problem here is that there is agreed upon feature set for small systems.
    Do you need threads, mmap, etc.? Some people do, other people don't.

    Minix 3 does have the advantage that a lot stuff is (drivers) and will be
    (filesystems) started from rc scripts. If you don't want it, delete it
    from the scripts and delete it from the source tree and it is gone.

    Other features, such as threads and mmap are likely to become permanent
    parts of the system, and cannot be deleted easily.


    --
    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

  8. Re: Info required on minix implementation status

    > There are not enough Minix 3 developers to turn it into a big fat OS.
    Hire me .


  9. Re: Info required on minix implementation status

    Philip Homburg wrote:

    > There are not enough Minix 3 developers to turn it into a big fat OS.


    I don't know much about the actual details, but throwing X into Minix 3
    might soon escalate into throwing GTK+ and Firefox and Gnome and KDE
    into Minix 3. Then everybody would use those, and someone would need to
    start over again. Maybe with Microix 1 or Minix 4.

    Think about Apple Macintosh System 7. The simple feel and usability it
    had. Something that would combine the power and reliability of Minix's
    roots and the elegance of a simple, standardized, GUI-based system. I do
    know System 7 did not have multi-user or pre-emptive multitasking or
    TCP/IP or OpenGL.

    But is it possible to have a modern GUI system with multi-user
    pre-emptive multitasking, OpenGL, sound, video and printing in a 486-66
    or a 60MHz P54C Pentium? If it is, then Minix 3 could aim at that, and
    hit something between it and KDE/Gnome/linux/Windows.

    Win3.11 and Apple's System 6 and System 7 prove us that one does not
    need more than 1MB of RAM to have a GUI and a file manager.

    For a more modern example, see what BeOS did and HaikuOS is doing again.
    Whatever Minix 3 will do, it should be at least as good with resources
    as BeOS or HaikuOS.

    -Kimmo S.
    --
    A broad path is not a broad heart, but a broad conscience.

  10. Re: Info required on minix implementation status


    "Kimmo Sundqvist" wrote
    in message news:GgbVg.26762$Rm5.21639@reader1.news.jippii.net ...
    > Philip Homburg wrote:
    >
    >> There are not enough Minix 3 developers to turn it into a big fat OS.

    >
    > I don't know much about the actual details, but throwing X into Minix 3
    > might soon escalate into throwing GTK+ and Firefox and Gnome and KDE into
    > Minix 3. Then everybody would use those, and someone would need to start
    > over again. Maybe with Microix 1 or Minix 4.
    >
    > Think about Apple Macintosh System 7. The simple feel and usability it
    > had. Something that would combine the power and reliability of Minix's
    > roots and the elegance of a simple, standardized, GUI-based system. I do
    > know System 7 did not have multi-user or pre-emptive multitasking or
    > TCP/IP or OpenGL.
    >
    > But is it possible to have a modern GUI system with multi-user pre-emptive
    > multitasking, OpenGL, sound, video and printing in a 486-66 or a 60MHz
    > P54C Pentium? If it is, then Minix 3 could aim at that, and hit something
    > between it and KDE/Gnome/linux/Windows.
    >
    > Win3.11 and Apple's System 6 and System 7 prove us that one does not need
    > more than 1MB of RAM to have a GUI and a file manager.
    >
    > For a more modern example, see what BeOS did and HaikuOS is doing again.
    > Whatever Minix 3 will do, it should be at least as good with resources as
    > BeOS or HaikuOS.


    Contiki seems to have functionality and direction that may have relevance
    to Minix development:

    http://www.sics.se/~adam/contiki/

    Tony



+ Reply to Thread