[Adeos-main] RTOS over Adeos document

[Adeos-main] RTOS over Adeos document

[Girish Wadhwani]

Hello,

The PDF and PS versions seem to have only one page,
the other pages seem to be missing. I downloaded it
from:
http://www.opersys.com/adeos/index.html

BTW, is this the list where all Adoes discussions take
place? Or is there some other list. All I see are
announcements.


Thanks,
Girish

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[Adeos-main] Re: RTOS over Adeos document

[Philippe Gerum]

Hello,

Girish Wadhwani writes:
 > 
 > The PDF and PS versions seem to have only one page,
 > the other pages seem to be missing. I downloaded it
 > from:
 > http://www.opersys.com/adeos/index.html
 > 

Yep, there seems to be some font problems with the PDF version of this
document. Try reading the PDF file with gv instead of xpdf.

 > BTW, is this the list where all Adoes discussions take
 > place? Or is there some other list. All I see are
 > announcements.
 > 

Well... Yes, this should be the list where Adeos discussions take
place, but I must admit that I'm rather alone to consume the available
bandwidth with announcements right now. But look, you have just
doubled the weekly traffic! ;o)

Philippe.

Re: [Adeos-main] Re: RTOS over Adeos document

[Girish Wadhwani]

Hello,

 But look,
> you have just
> doubled the weekly traffic! ;o)

Let me triple it then:-)

I was wondering about Adeos's roadmap. Right now I see
three uses of Adeos:
1, Real time capabilities for Linux
2, Clustering for Linux and
3, Running multiple instances of Linux on the same
machine.

Which of these is the project working towards? I there
an explicit roadmap towards any?  I particular I am
interested in 3 and ways to possibly achieve it. I
think this would be useful to a lot of people. 

One approach would be to have a VMM and virtualize all
resources. This would involve the overhead of "world
switches" to the host OS and virtualization (with the
VMM running as an application on the host OS). You
would land up with something like VMWare and plex86
which would have little value.

The other approach would be the one mentioned in the
clustering paper i.e. make Linux aware of Adeos. This
brings up the question of how to get two or more
instances share resources and co-operate. A major
problem would be devices. Without virtualization, it
would invlove a huge number of changes  to drivers,
making it difficult to develop and maintain, if one
were to support all the devices that Linux currently
does. In this case the purpose of Adeos would be to
multiplex access between multiple instances, which
would be aware of each other and avoid stepping on eac
others toes. The upside would be that you would have
significant performance advantages over the VMM
method. 

Any thoughts on this? Or am I completely off the mark?
The information I found on the Adeos papers did not go
into much detail as to how things would be implemented


Cheers,
Girish 

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: [Adeos-main] Re: RTOS over Adeos document

[Karim Yaghmour]

Girish Wadhwani wrote:
>  But look,
> > you have just
> > doubled the weekly traffic! ;o)
> 
> Let me triple it then:-)

Fantastic, let's have fun then ;)

> I was wondering about Adeos's roadmap. Right now I see
> three uses of Adeos:
> 1, Real time capabilities for Linux
> 2, Clustering for Linux and
> 3, Running multiple instances of Linux on the same
> machine.

Indeed.

> Which of these is the project working towards? I there
> an explicit roadmap towards any?  I particular I am
> interested in 3 and ways to possibly achieve it. I
> think this would be useful to a lot of people.

Agreed. If nothing else, you could try new drivers and not care about
a second Linux dying.

> One approach would be to have a VMM and virtualize all
> resources. This would involve the overhead of "world
> switches" to the host OS and virtualization (with the
> VMM running as an application on the host OS). You
> would land up with something like VMWare and plex86
> which would have little value.

No really interesting, we might as well just extend plex86 if we're
going down this road ...

> The other approach would be the one mentioned in the
> clustering paper i.e. make Linux aware of Adeos. This
> brings up the question of how to get two or more
> instances share resources and co-operate. A major
> problem would be devices. Without virtualization, it
> would invlove a huge number of changes  to drivers,
> making it difficult to develop and maintain, if one
> were to support all the devices that Linux currently
> does.

No, you don't need to do that. As I explain in the clustering paper,
all you need is to modify that PCI allocation code to first ask
Adeos about the components it should be seeing. There is no need to
change any of the drivers. We do need to make sure, nevertheless,
that any extra copies of Linux that boots don't reinitialize any
available ISA hardware, but I don't see this as much of a problem.

Of course, this involves that no two instances of Linux share the
same hardware. Which is just fine for what Adeos is supposed to
do. If you need to share hardware devices among OS instances, then
you certainly need somethine like VMWare or plex86. Sharing
hardware devices isn't part of Adeos' mandate.

> In this case the purpose of Adeos would be to
> multiplex access between multiple instances, which
> would be aware of each other and avoid stepping on eac
> others toes. The upside would be that you would have
> significant performance advantages over the VMM
> method.

We don't need to do this. Since any extra Linux doesn't even see the
PCI hardware it isn't supposed to use, there is no need to make sure
that the various Linux don't step on each other. The only possible
problem is if you have a Linux making random physical memory accesses,
but if that's the case then it's a bug and it has to be fixed.

As for how the various Linux instances are supposed to communicate
with a single Adeos instance, I first thought that soft ints could
be used, but these may turn out to be expensive. Instead, I think
we could reserve a MB or two in physical memory where we would place
the Adeos code and data. All Linux instances would map this instance
into their virtual address space and call upon it as they would
any other code.

> Any thoughts on this? Or am I completely off the mark?
> The information I found on the Adeos papers did not go
> into much detail as to how things would be implemented

The papers are really meant to be "food for thought". For sure they
can't explain every corner case. If that were true then I might have
just as well written the thing to start with ;)

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] Re: RTOS over Adeos document

[Jacob Gorm Hansen]

On Mon, Nov 04, 2002 at 10:20:23AM -0500, Karim Yaghmour wrote:
> 
> > 3, Running multiple instances of Linux on the same
> > machine.

Hi,

just wanted to point you all to our project about running multiple
linuxes on the same machine, as well as migrating them quickly between
machines: http://www.nomadbios.dk

best,
Jacob

Re: [Adeos-main] Re: RTOS over Adeos document

[Karim Yaghmour]

Jacob Gorm Hansen wrote:
> just wanted to point you all to our project about running multiple
> linuxes on the same machine, as well as migrating them quickly between
> machines: http://www.nomadbios.dk

Quite interesting. It would be even more interesting to see the source.

The only thing that dampens my enthusiasm for this is the dependency on
L4. I don't mean to debate its merits, but you're really dragging some
else's limitations. Would you be interested to interface with the Adeos
project for future work?

Also, I suppose the migration capability requires that both systems have
the exact same hardware and the exact same data on disk (or maybe this
is why you discuss NFS boot on the project's site)?

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] Re: RTOS over Adeos document

[Jacob Gorm Hansen]

On Mon, Nov 04, 2002 at 12:05:44PM -0500, Karim Yaghmour wrote:
> 
> Jacob Gorm Hansen wrote:
> > just wanted to point you all to our project about running multiple
> > linuxes on the same machine, as well as migrating them quickly between
> > machines: http://www.nomadbios.dk
> 
> Quite interesting. It would be even more interesting to see the source.

Yes, we are working on a public CVS repo, should be up in a few minutes.
Check back soon for access details.

> The only thing that dampens my enthusiasm for this is the dependency on
> L4. I don't mean to debate its merits, but you're really dragging some
> else's limitations. Would you be interested to interface with the Adeos
> project for future work?

We had a number of reasons for choosing L4:

- It has recursive address spaces, which we need.
- It has fast IPC.
- It has a working Linux implementation.
- It has OSKit driver and TCP/IP support.

Having to deal with multiple tasks for each Linux was extremely complex
though, and might be a good reason for choosing a nano-kernel next time.

If Adeos gets spaces like Space, then it would be interesting.
Otherwise I don't think it is possible, because we need to protect guest
OSes against eachother. 

> Also, I suppose the migration capability requires that both systems have
> the exact same hardware and the exact same data on disk (or maybe this
> is why you discuss NFS boot on the project's site)?

Exactly ;-)
Currently only networking is abstracted, but this means that it may run
on any hardware, as long as it is supported by oskit.

> Karim

best,
jacob

Re: [Adeos-main] Re: RTOS over Adeos document

[Philippe Gerum]

Girish Wadhwani wrote:
 > 
 > I was wondering about Adeos's roadmap. Right now I see
 > three uses of Adeos:
 > 1, Real time capabilities for Linux
 > 2, Clustering for Linux and
 > 3, Running multiple instances of Linux on the same
 > machine.
 > 
 > Which of these is the project working towards? I there
 > an explicit roadmap towards any?  I particular I am
 > interested in 3 and ways to possibly achieve it. I
 > think this would be useful to a lot of people. 
 > 

I would say #1, #3 then #2 since being able to run multiple copies of
Linux first would hopefully pave the way to efficient SMP clustering
over Adeos.  Seeking #1 was IMHO the fastest path to get a functional
and stable base to build onto. Once it's rock-solid for stressed
real-time systems running along Linux, we should have a reasonable
confidence for other kinds of use.

#1 is no more experimental since we already had some positive feedback
from demanding projects such as RTAI, Xenomai, or some company-lead
efforts who succeeded in coupling Adeos to their in-house real-time
kernel. The real problem now is the portability issue: Adeos is
x86-only, and this is bad, it sounds as a lack of maturity at the very
least. I hope the recent modularization effort will be an incentive to
port it to other archs.  However, this problem does not preclude us
from initiating #3 now.

 > One approach would be to have a VMM and virtualize all
 > resources. This would involve the overhead of "world
 > switches" to the host OS and virtualization (with the
 > VMM running as an application on the host OS). You
 > would land up with something like VMWare and plex86
 > which would have little value.
 > 

Agreed. I would rather call for a sound compromise between
functionality and performance, keeping the wild horse of
virtualization in manageable bounds.

 > The other approach would be the one mentioned in the
 > clustering paper i.e. make Linux aware of Adeos. This
 > brings up the question of how to get two or more
 > instances share resources and co-operate. A major
 > problem would be devices. Without virtualization, it
 > would invlove a huge number of changes  to drivers,
 > making it difficult to develop and maintain, if one
 > were to support all the devices that Linux currently
 > does. In this case the purpose of Adeos would be to
 > multiplex access between multiple instances, which
 > would be aware of each other and avoid stepping on eac
 > others toes. The upside would be that you would have
 > significant performance advantages over the VMM
 > method. 
 > 

I like the idea of giving exclusive control over the devices on a
per-domain/os basis instead of trying to share them at all cost. It
sounds more natural and less invasive.

 > Any thoughts on this? Or am I completely off the mark?
 > The information I found on the Adeos papers did not go
 > into much detail as to how things would be implemented
 > 

Yes, but at least they were well-written enough so that even _I_ had
been able to understand them and implement something that resembles
Karim's idea... So there's definitely room for unbounded hope! :o>

Philippe.

Re: [Adeos-main] Re: RTOS over Adeos document

[Karim Yaghmour]

Jacob Gorm Hansen wrote:
> If Adeos gets spaces like Space, then it would be interesting.
> Otherwise I don't think it is possible, because we need to protect guest
> OSes against eachother.

You don't need to do that if each OS is stable and doesn't behave
randomly, which we assume is a fine description of Linux. As long
as the PCI probe is modified to only reveal the devices the OS
instance is supposed to see, then all other hardware should be
out of reach.

BTW, I've went through the L4Linux source code briefly and it was
interesting to see how they take care of cli/sti. They too redefine
those functions :) However, they use L4's IPC mechanisms to
implement cli/sti, which is kind of interesting.

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] Re: RTOS over Adeos document

[Girish Wadhwani]

Hello Jacob,


> Yes, we are working on a public CVS repo, should be
> up in a few minutes.
> Check back soon for access details.
>
Could you let me know how to access the source. I
didn't see any links from the site.

How exactly does the project deal with device access?

Cheers,
Girish 


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: [Adeos-main] Re: RTOS over Adeos document

[Jacob Gorm Hansen]

On Tue, 2002-11-05 at 10:08, Girish Wadhwani wrote:
> Hello Jacob,
> 
> 
> > Yes, we are working on a public CVS repo, should be
> > up in a few minutes.
> > Check back soon for access details.
> >
> Could you let me know how to access the source. I
> didn't see any links from the site.

The pserver didn't get to work, I've put up some source tarballs
instead.

See the README for more info.

best,
Jacob

Re: [Adeos-main] Re: RTOS over Adeos document

[Girish Wadhwani]

Hello Karim,

> Of course, this involves that no two instances of
> Linux share the
> same hardware. Which is just fine for what Adeos is
> supposed to
> do. If you need to share hardware devices among OS
> instances, then
> you certainly need somethine like VMWare or plex86.
> Sharing
> hardware devices isn't part of Adeos' mandate.

Wouldn't this severly limit what Adeos could be used
for?
The hardware will have to scale with the no. of OSes
in  
use. It would be too expenive to use it for
allpications like hosting, etc. The only resources
that are  shared are the cpu and memory making it not
that beneficial to be running multiple OSes.
Clustering still works though:-)

-Girish
 
> > In this case the purpose of Adeos would be to
> > multiplex access between multiple instances, which
> > would be aware of each other and avoid stepping on
> eac
> > others toes. The upside would be that you would
> have
> > significant performance advantages over the VMM
> > method.
> 
> We don't need to do this. Since any extra Linux
> doesn't even see the
> PCI hardware it isn't supposed to use, there is no
> need to make sure
> that the various Linux don't step on each other. The
> only possible
> problem is if you have a Linux making random
> physical memory accesses,
> but if that's the case then it's a bug and it has to
> be fixed.
> 
> As for how the various Linux instances are supposed
> to communicate
> with a single Adeos instance, I first thought that
> soft ints could
> be used, but these may turn out to be expensive.
> Instead, I think
> we could reserve a MB or two in physical memory
> where we would place
> the Adeos code and data. All Linux instances would
> map this instance
> into their virtual address space and call upon it as
> they would
> any other code.
> 
> > Any thoughts on this? Or am I completely off the
> mark?
> > The information I found on the Adeos papers did
> not go
> > into much detail as to how things would be
> implemented
> 
> The papers are really meant to be "food for
> thought". For sure they
> can't explain every corner case. If that were true
> then I might have
> just as well written the thing to start with ;)
> 
> Karim
> 
> ===================================================
>                  Karim Yaghmour
>                karim@domain.hid
>       Embedded and Real-Time Linux Expert
> ===================================================
> 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> http://mail.nongnu.org/mailman/listinfo/adeos-main


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: [Adeos-main] Re: RTOS over Adeos document

[Karim Yaghmour]

Girish Wadhwani wrote:
> Wouldn't this severly limit what Adeos could be used
> for?
> The hardware will have to scale with the no. of OSes
> in
> use. It would be too expenive to use it for
> allpications like hosting, etc.

If you need to share a machine for hosting, then your best bet is
to use Jacques Gelinas' virtual servers:
http://www.solucorp.qc.ca/miscprj/s_context.hc

This is actually already used by a few hosting companies and it
is much better adapted to this job than anything Adeos can do.

> The only resources
> that are  shared are the cpu and memory making it not
> that beneficial to be running multiple OSes.

I, for one, really like to idea of having 2 completely separate
OSes each running with their separate hardware linked using a
RAM-based virtual Ethernet. I don't like the idea of having to
make special modifications to block device drivers and I don't
like the idea of having layers of block requests (a-la VMWare).
This doesn't mean other folks can't find those things of some use.
But from my perspective, nanokernels are better off really being
"nano" ...

Karim

===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] Re: RTOS over Adeos document

[Jacob Gorm Hansen]

On Mon, 2002-11-04 at 19:39, Karim Yaghmour wrote:
> 
> Jacob Gorm Hansen wrote:
> > If Adeos gets spaces like Space, then it would be interesting.
> > Otherwise I don't think it is possible, because we need to protect guest
> > OSes against eachother.
> 
> You don't need to do that if each OS is stable and doesn't behave
> randomly, which we assume is a fine description of Linux. As long
> as the PCI probe is modified to only reveal the devices the OS
> instance is supposed to see, then all other hardware should be
> out of reach.

I agree for the purposes of running a disco-like setup on a large MP
machine.

Our purpose with nomadbios is to make operating systems a kind of mobile
agents, so they cannot be trusted and we need MMU protection. If Grids
are to over happen then I think something like this is needed.

Best,
Jacob