Menu

Anybody home???

2001-10-13
2002-01-09
  • Bruce Frederiksen

    Is this project for real?

    Have you got any more info on what you're trying to do?

    Looking for any help?

     
    • Cesare Zavattari

      Hi mtnyogi,
      sorry for the big delay, but we didn't think anyone had seen our page yet! :)

      At the beginning our idea was to use some microkernel
      already done and some library as OSKit.
      But it's more funny starting from the ground, so
      we are coding a kernel from scratch in asm and C, only for very low level stuff like initialization of memory,
      interrupts, timer, ecc.
      We want this kernel be a sort of microkernel.
      We have to decide the protocols to use with this mkernel.
      The next step will be to port the ocaml virtual machine
      (extended with kernel communication layer) to MyNOS.
      At this point the funny job will start! :)
      Maybe the first thing implemented in ocaml will be the
      file system.

      At this time we have:

      - bootloader
      - A20 enabled
      - protected mode
      - paging enabled

      what we miss (in short term) is:

      1 - fully memory management
      2 - timer and interrupts controller programming
      3 - task switching support

      I'm actually working on these points (but I have not
      much time to spend...).
      For (1) we can leave the swap support outside the mkernel (now I don't have a file system!).
      For (2) is not a problem: GazOS do it with very little
      code (we could use it...).
      The third point will come when (1) and (2) will be done :)

      In the next days I'll try to put the source code on CVS.

      Would you like to join us?
      What are your skills? What about your interesses?
      Do you know Ocaml?

      Bye :)

       
      • Bruce Frederiksen

        OK, so I have another question:

        given that ocaml is a "safe" language, are you considering an OS that doesn't try to isolate applications from each other only to have to provide ways of communicating?  What I mean is that traditional OS philosophy is that the OS must protect applications from each other.  If applications are written in a safe language where it is not possible to scribble on memory, then this protection seems no longer necessary.

        Indeed, with the memory management built into ocaml, could all applications be run within one address space?  One heap/garbage collector?  This makes it much easier for applications to talk to each other.  Also, it would no longer seem necessary to ever take the processor out of supervisor mode so that all instructions are always legal.  Thus, device access could be done by simple subroutines without requiring a switch in processor state in order to be allowed access to the hardware.

        As to your questions concerning my interest in your project.  I think that it is still too early to tell.  If you have some ideas about what an OS should be with safe applications, I'm interested.

        Skills: analysis, high-level design/architecture.  object-oriented design/architecture (experience in C++, but please don't hole that against me! :-)

        Weaknesses: My biggest weakness is probably an inability to sell.

        Interests: What does an OS look like that isn't required to offer protection from unsafe code.  One address space, always in supervisor mode.  Traditional OSes have the "process" as their centerpiece.  The process revolves around a protected address space.  To kill the process, discard the address space!  How to abort tasks that share an address space?  Does the garbage collector handle it?

        I'm also interested in non-stack based models of execution.  Historically, computer programs ran in "batch" mode.  When started, they processed a batch of input and terminated.  The stack-based idea of a function calls suited this well.  Today, both UI and client-server programming have moved towards event driven models that no longer simply run start to finish.  Rather they respond to many events, possibly starting a second event while still processing the first.  Thus, the strict execution ordering imposed by the stack gets in the way -- it doesn't allow you to start a second function before the first one has finished.

        I have been programming computers professionally since 1975.  I started in COBOL, and have dabbled in a long list of programming languages.  I have programmed professionally in C++ since around 1987.  In C++, I have developed my own ideas of what object-oriented programming is (interchangeable parts) and isn't (nearly every description I've seen of it).  I have no experience implementing any OS.  About 3 years ago I "retired" from professional programming and now live in the foothills of the Sierra Nevada mountains in California.  Over the last 6 months or so, I've started playing around with SML/NJ.  I have read a tutorial on OCAML but have not done any programming in it.

        I also have no experience with developing free software, though I have worked on a few projects at home where several developers were involved.  These were projects for hire with deadlines and strict expectations as to what the program should do.

        I am running SuSE Linux 7.2 on a PC with 192Mb of RAM.  I have left space on my hard drive for OS experimentation (I can add a partition for MyNOS).

        Let me know whether you think that there is a fit or not, and what you might see me doing (yes I can program too! :-).

        BTW, I have no interest in GUI programming, I might get involved in some high-level GUI design/architecture, but am generally not interested in pushing pixels around the screen...

         
    • alley

      alley - 2002-01-06

      Cesare, it'd be a good idea for us developers to actually put a notification on these forums, so that we get acknowledged when somebody writes, don't you think?

       
      • Cesare Zavattari

        yes, I did it yesterday :)

         
    • alley

      alley - 2002-01-09

      Hi, mtnyogi,

        we are very glad to see your interest in the project. I'd like to take
      the time to answer some of your questions. First of all, this is an open
      discussion forum, and therefore there is nothing we have planned that
      couldn't be changed by something that's said here. We'll happily accept
      any suggestion we find interesting.

      I think you are suggesting we build a kernel with no concern of any
      kind about memory protection, relaying on the fact that ocaml is a
      safe language. This is actually an interesting thought which we
      discussed about, and this is what we came out with.

      Our current idea for the structure of the OS would be as follows:
      building a "standard" microkernel, and by "standard" I mean a
      memory-protecting kernel allowing context switch and communication,
      written in C (assembler parts will be required...). We do indeed
      want to keep the kernel very small, and the reason will be obvious.

      On top of such a microkernel, we plan to deploy (alongside necessary
      services such as memory management or file system manager) an OCAML
      virtual machine on which we'll run an ocaml program which will serve
      as user-side kernel (and which Cesare likes to call 'Virtual Kernel').

      The effect (to the user) is an ocaml kernel, in which ocaml "processes"
      DO indeed share the same address space, and DO in fact run as superuser,
      for the ocaml vm is a system service, and therefore a superuser process.
      An issue with this, however, is that an ocaml VM does not interpret
      ocaml source, but runs instead instruction of the ocaml vm which are
      typically (but not necessarily) obtained from the compilation of
      ocaml code. Now, compilation performs type checking and all, ensuring
      code safety, but it would be possible to write malicious code using
      direct ocaml vm instructions (I mean 'malicious' in the sense that
      memory protection could not be guaranteed). I am not an ocaml expert
      myself, so I'm ready and eager to accept and study any suggestion.
      We could force JIT compilation of source code, meaning the service would
      include not only an ocaml vm, but a compiler as well. Overhead would only
      be on program startup.

      Now, you may ask: why would you put a microkernel under the ocaml
      service, rather than making the ocaml vm the kernel itself? There
      are several things we took into account. The first is hardware. In
      ocaml, and therefore in the ocaml vm native language, there is no way
      (actually there MAY be) to write device drivers for console, disks,
      video cards and such. Besides, it'd make everything very very hard,
      and we'd have to give up many features. There are plenty of such
      drivers, all written in C, which we could take e.g. from Linux
      kernel distribution. The same goes for the ocaml vm: they're all
      written exploiting underlying OS functionalities. Rather than rewriting
      all that from scratch, we would like to concentrate on the 'core' of
      the system, possibly adapting some existing piece of software. We do,
      however, want to write the microkernel ourselves, first as an occasion
      to learn such things, and second because we want to make sure it is
      perfectly tweaked to serve our purposes. While suitable ocaml vm
      exists and can therefore be reused, we will have to make modifications
      to allow, for instance, preemptiveness in task switching. The ocaml
      kernel, instead, will have to be written entirely, as we plan on
      exposing all your typical OS functionalities via ocaml. Services like
      GUI (as you mention it), should ALL be written in ocaml, using only
      low-level capabilities offered by C device drivers (we may have to
      extend the language somehow, here).

      Of course, the fact of having a microkernel would enable us (in theory)
      to have other vm's running alongside the ocaml one, a POSIX one,
      for instance, allowing compilation of posix code would be neat, to
      inherit posix programs. One of the features of the microkernel would
      be, of course, to allow seamless communication among such vm's, so
      that in a dream world we could have some sort of common language runtime
      across virtual platform, though I sould probably wake up, now. :)

      My skills are those of a computer science PhD student, in my last
      year of PhD here at the university of Pisa. While my research area
      is that of Artificial Intelligence, and particularly natural language,
      I like to devote my free time (at least the one I spend on a computer)
      to operating systems, and particularly the idea of having one based
      on a safe, strongly typed, interpreted one. My experience with LISP is
      that it'd be such a boost (in coding style) to use a high-level
      language (as opposed to low-level C) for many of an operating system's
      services, that we started this project to verify that. My programming
      experiences embrace all major languages (not ocaml, however...).

      Finally: both me and Cesare are very busy in our own living, and while
      MyNos is an idea we had a long time ago, it's only maybe a week that
      we've actually put our mind to it. We intend to stick at it, but we
      really haven't much free time off the day, so development is likely to
      be slow and inconstant. We will happily let in anyone who wants to join,
      anyway.

       
      • Cesare Zavattari

        > We could force JIT compilation of source code,
        > meaning the service would include not only an
        > ocaml vm, but a compiler as well. Overhead
        > would only be on program startup.

        the best way is to compile only once, then label that code as "trusted code" on file system too, so you don't have to compile the same code every time you start the VM.

        One feature we want is virtual kernels (VKs) communication, not making differences between local VK and remote VK. To do so, you have to send code from a VK to another one. Well, you must trust in the sender VK, otherwise you must force it to send the source to compile it yourself.

        I'm a master degree. My research area
        is that of Artificial Intelligence too (particularly multi-agents systems) but I worked with Alessandro on natural language processing too.
        Now my job concerns networks. Like Alessandro
        I like to devote my free time to operating systems and free software (look at asforza4.sourceforge.net for a little but funny project :)
        Bye

         

Log in to post a comment.