Cooperative Linux

On Sat, Jul 10, 2004 at 10:08:29PM -0700, Steven Edwards wrote:

> We are still working on improving ReactOS to run CoLinux. Here are a
> few of the ideas we have to make ReactOS/Windows and CoLinux play nicer
> together. I know some of these ideas have been bounced around already
> and we have not been much of a help yet but things are coming along.
> 
> Anyway here are a few ideas Arty and I hashed out while reviewing the
> status of CoLinux on ReactOS.
> 
> 1. Think about simple stuff like a rootless X server and a the Xdnd
> extention hooking in to OLE and DCOM like in Wine only in reverse. The
> end user could cut/copy/paste text/images what have you via this
> service running on Windows in the Xserver.

Interesting. I guess this means something needs to translate between
Linux's dragged objects and Windows's dragged objects. Wouldn't be
that hard I guess.
 
> 2. the fs interface - you could develop a driver and mount parts of
> linux or Windows files systems anywhere you want you can basically
> already do it with windows file sharing, but you'd get a faster result
> using a shared memory segment and local signals.
>
> or
> 
> If it could do something like the old UMSDOS but a little more
> educated, then you could scrap the disk images entirely. Like umsdos
> except that it doesn't mangle file names as much. you might call it
> umsvfat. I guess if you are using a Windows driver it could sit higher
> up on the layer so you dont have to worry about Linux not being able to
> read NTFS you could off load the VFS on the Windows driver.

The latter is the direction coLinux is going to. hostfs / humfs-like 
support which will be based on methods from UMSDOS. This is still waiting 
to be implemented.
 
> 3. User management. You could develop a PAM module that hooks in to
> lsass and MSV10 authenication so the user would never have to log in to
> "Linux", they would be authenticated when the Gina authentics them. You
> could do it now with kerberos really and a special login prog (or
> special xdmcp) actually, you could do it all with xdmcp if you were
> clever

This will require a special communication channel between the running
Linux and Windows. Remember that it is not possible to transfer data
between the two by using conventional function calls, so message passing
is at hand here. 

To do this, the PAM module you are talking about will need to interface 
with a special driver that we will add in the Linux kernel. I don't see
any problem to develop this.
 
> 4. Run the X server on linux and give a nice chunk of dib section to it
> directly? that would allow fbcon and svga programs to run  as well as
> making X pretty fast but restoring programs' ability to use the render
> extension and MIT-SHM.

This sounds like the frame buffer functionality we are planing to add, 
which basically means map a physical memory direct video buffer, allowing
for almost no overhead in rendering.

> Anyway there they are. Like I said I know you have not seen much from
> us yet as we are still working to make the damn thing stable on ReactOS
> but these are some nice things we would like to see added once we get
> it going.

It looks like our ideas are set on the same goals, perhaps with 
collaboration we can add these features.

-- 
Dan Aloni
da-x@...

On Sat, Jul 10, 2004 at 10:08:29PM -0700, Steven Edwards wrote:

> Anyway there they are. Like I said I know you have not seen much from
> us yet as we are still working to make the damn thing stable on ReactOS
> but these are some nice things we would like to see added once we get
> it going.

I wonder why it is currently unstable on ReactOS. Can you elaborate?

BTW, if you have anything that can improve coLinux's stability on 
Windows, don't hasitate to send a patch. Also, if you make some 
improvements (such as better physical page allocation), please send 
them over.

-- 
Dan Aloni
da-x@...

Hello Dan,

I've been watching coLinux since its introduction and have been very
excited about this project. As you probably remember, I suggested
early on that there are probably quite a few interesting possibilities
of interfacing between the Adeos nanokernel and coLinux. Here's one
issue where I think something like Adeos comes in handy:

Dan Aloni wrote:
> This will require a special communication channel between the running
> Linux and Windows. Remember that it is not possible to transfer data
> between the two by using conventional function calls, so message passing
> is at hand here. 

This is something that is relatively straight-forward with Adeos given
that it provides virtual interrupts. These act like real interrupts for
the clients OSes, but can be allocated dynamically using a call to
adeos_alloc_irq(). Using this virtual IRQ, a very efficient inter-OS
communication mechanism can be implemented.

Again, this is just one of many aspects of where coLinux and Adeos can
interface. What I'd really like to see is a combination of Adeos'
capability to deal with very complex sharing of interrupts between the
various OSes and coLinux's ability to share the same physical address
space between multiple OSes while ensuring proper OS context switching
(especially since coLinux can now run alongside Linux itself.) Ideally,
we could have a nanokernel/monitor residing in an isolated RAM region
from which it can service multiple OSes or multiple instances of the
same OS, the latter having _many_ practical implications for a wide
range of Linux applications (like SMP clusters for example.)

Note that Adeos currently runs on PPC and ARM in addition to x86.

I will be at OLS next week and will try my best to attend your talk.
The OLS organizers really should have tried _not_ to put this talk in
the same time as Jonathan Corbet's summary of the Kernel Summit (aka
the direction where 2.7 is going.)

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@... || 1-866-677-4546

Hello Aloni.

I worry a little that if you have some mis-understanding.
See my comment of your posting about coLinux FB.

BTW, Sorry, Lucas, the message I have to post about FB is delayed.
Writing English is so troublesome issue for me.

                                    --- Okajima.

>On Sat, Jul 10, 2004 at 10:08:29PM -0700, Steven Edwards wrote:
>
>> We are still working on improving ReactOS to run CoLinux. Here are a
>> few of the ideas we have to make ReactOS/Windows and CoLinux play nicer
>> together. I know some of these ideas have been bounced around already
>> and we have not been much of a help yet but things are coming along.
>> 
>> Anyway here are a few ideas Arty and I hashed out while reviewing the
>> status of CoLinux on ReactOS.
>> 
>> 1. Think about simple stuff like a rootless X server and a the Xdnd
>> extention hooking in to OLE and DCOM like in Wine only in reverse. The
>> end user could cut/copy/paste text/images what have you via this
>> service running on Windows in the Xserver.
>
>Interesting. I guess this means something needs to translate between
>Linux's dragged objects and Windows's dragged objects. Wouldn't be
>that hard I guess.
> 

Yeah, of course, it is good. And traslating function is necessary,
at least for Japanese text. Because, we have three encoding for texts,
and usually Linux one and Windows one is different.


>> 4. Run the X server on linux and give a nice chunk of dib section to it
>> directly? that would allow fbcon and svga programs to run  as well as
>> making X pretty fast but restoring programs' ability to use the render
>> extension and MIT-SHM.
>
>This sounds like the frame buffer functionality we are planing to add, 
>which basically means map a physical memory direct video buffer, allowing
>for almost no overhead in rendering.
>

You plan to use Ian Pratt's User Land I/O Technology? Except using such kind
of technology, I cant imagine how to utilize H/W acceleration safely from coLinux.
I am sure that you currently have a very good information source near you ;-).
Ian Pratt and Keith Packard must have an interest about this issue.