Hello again. I'm sorry for this awful delay but I'm almost always in hurry
:-).
> In message <Pine.LNX.3.96.980821010156.25221B-100000@localhost>, Tomasz Rola
> wr
> ites:
> +-----
> | I've been looking for some online materials about virtual machines on IBM
> | System 360 and found almost nothing (I know, it was long long ago...). In
> +--->8
>
> S\360 didn't have virtual machines. S\370 did.
That was a mistake...
>
> Basically, the S\370's CPU was capable of completely virtualizing itself.
> This is actually a fairly rare capability: x86, for example, can only
> virtualize a subset of itself (80286 real mode).
>
> Given a CPU that can completely virtualize itself, software can be written
Do you know how this was done? Speaking in terms of registers etc.
Although I'm not a hardware guy I can understand a little - and sometimes
it really helps :-).
> to present multiple virtual CPUs. In IBM's VM/SP the CP (control program)
> did this. Each virtual CPU could run a different OS: CMS (think CP/M on a
> mainframe), MVS, Amdahl UTS (Unix clone), etc. CP also allowed the virtual
> machines to communicate with each other via simulated card readers/card
> punches and the RSCS software.
So, correct me if I am wrong, there was also some software that drove
everything else - the CP. And the CP provided services to everything run
above it? So it was really CP that made virtuallisation capabilities of
CPU usable.
Were all those other OSes, like CMS, UTS etc, capable of running on the
same hardware without CP program? I mean, were they specially written to
be used ontop of CP or they were able to run on real hardware? Was it
possible to run anything without the CP? I suppose that UTS without CP
could have made simple Unix machine of S/370 - no virtual machines
posiible in such case.
The concept of communication going between different virtual machines is
very cool for me. I haven't thought about it.
>
> | Also, I'm interested in JVM (Java Virtual Machine) built into the kernel.
> +--->8
>
> I don't think that one would get Linus' blessing.
I have big respect for Linus Torvalds, but he made kernel sources GPLed.
So, he allowed to change the source, with respect to GPL terms. Of course,
if he decides someday that JVM doesn't go into the main trunk - that's his
will.
Perhaps it is good moment to say something more about my first letter to
this group :-). So...
The genesis.
Some time ago I found a wishlist for future kernel. I don't remember who
made it - sorry for this. Among many ideas there were two - virtual
machines and JVM. I don't remember this page very well now but those two
seemed interesting to me. Later, I decided to begin some kind of project
and decided it should be something related to kernel. The nature of this
project is such that:
1. I wouldn't like to say more about its nature before it's finished -
not because I'm so arrogant ram but simply because I don't like to talk
much about nonexistent things.
2. It is research, not commercial
3. The output of the project will be available on my site as I make it in
the future, the same with sources so that some brave heart could try it.
4. After it's finished I will very probably make it GPLed (I hope)
5. Before it's finished I will have to write it myself but...
6. ... but I will be open to suggestions, willing to discuss (to the
extent my rough English will make it possible) and to help those who will
try to evaluate it.
So, after some visualisation I picked three ideas. I asked about them here
because I don't like walking after someone's trails :-). And, also, I
would like to tell people who might be interested about it.
After writing some preliminary paper, and if one of these ideas will be
accepted (I can also put a paper available on the net, but it will
have to be translated from Polish to make it readable for non-Poles)
I'll try to implement it. After successful implementation (or rather, if
it ever happens ;-) ) I'll probably use it to do some additional work - in
general, I plan to evaluate the usefulness of the solution.
Well, I am going to do this anyway. With blessings or curses :-). The only
thing that might send all the project to trash would be when I'd been
suggested to choose something different - perhaps from the OO area.
>
> | Third problem I would like to ask about is if there is any work going to
> | make Linux kernel hotswappable? I mean, having kernel, say, 2.0.33 I'd
> +--->8
>
> Someone was looking at it, but it's not at all easy. And if it's a bug that
> you're trying to get away from it may well be impossible.
No, I think removing bugs with the kernel isn't good - the better way is
to remove them _from_ the kernel :-). This idea in difficult to implement
and area of its use is narrow. I'll probably not do it - I feel more
interested in two other above. However, I can imagine such cases when time
matters and it is much faster to replace kernel than to restart the whole
system.
I've been told, that it would be difficult to deal with device
states. That's right, but it wouldn't be much more difficult than freezing
a process and restoring it later :-).
>
> --
> brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
> system administrator [WAY too many hats] allbery@ece.cmu.edu
> electrical and computer engineering KF8NH
> carnegie mellon university
>
bye
T.
-- ** Tomasz Rola I am going to forward myself to /dev/null ** ** To check if data is really discarded there ** ** Or is it a gate to another Universe... ** ** mailto:rtomek@cis.com.pl , http://www.cis.com.pl **
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html