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.
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 :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this project for real?
Have you got any more info on what you're trying to do?
Looking for any help?
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 :)
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...
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?
yes, I did it yesterday :)
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.
> 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