Menu
▾
▴
colinux-devel
|
From: Steven E. <ste...@ya...> - 2004-01-27 20:38:36
|
Hello All, Now that the word is out its time to fill you guys in. Over the past few months I have been working with a Project called Cooperative Linux. Cooperative Linux allows you to the Linux kernel as a process under Windows NT/2K. With CoLinux you can run any linux application under Windows. http://www.colinux.org/?section=screenshots My plan is to work with the CoLinux team to integrate CoLinux in to Windows and ReactOS as a POSIX subsystem. They are very interested in working with us on this project and have linked to reactos.com on the website. http://www.colinux.org Currently CoLinux depends on a driver that allows it to use the hardware MMU. It also currently depends on cygwin to be compiled. The first steps for developing this for ReactOS and other Win32 hosts will be to remove the cygwin dependancy. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ |
|
From: Shachar S. <win...@sh...> - 2004-01-28 22:53:35
|
Steven Edwards wrote: >My plan is to work with the CoLinux team to integrate CoLinux in to >Windows and ReactOS as a POSIX subsystem. They are very interested in >working with us on this project and have linked to reactos.com on the >website. > > My entire experience with CoLinux has to do with Dan Aloni grabbing me at a random hall a few weeks ago and telling me about it (actually - the first he did it was about half a year ago, but he really got my attention, making me late for a meeting, this time around). While it's certainly an exiting project, I understood that it was NOT based on the Windows subsystem mechanism, but rather hacking your way into Windows NT's ring 0 using a device driver. While I'm a great fan of "if it works", wouldn't it be nicer, long run, to have a proper subsystem of it? Also, what are you planning on doing with graphic applications? CoLinux works by running a X server on the windows machine. That's probably not the best solution there is. How is the ReactOS windowing back-end implemented? Shachar |
|
From: Ian C. B. <ia...@bl...> - 2004-01-29 00:28:21
|
On Thu, Jan 29, 2004 at 12:42:30AM +0200, Shachar Shemesh wrote: > While it's certainly an exiting project, I understood that it was NOT > based on the Windows subsystem mechanism, but rather hacking your way > into Windows NT's ring 0 using a device driver. While I'm a great fan of > "if it works", wouldn't it be nicer, long run, to have a proper > subsystem of it? Why work within Microsoft's cludgy POSIX subsystem shenanigans? There's something very alluring to having a Linux kernel running at ring 0 in parallel with OTHER kernels. Think of Linux X86 images running on a Linux X86 host without UML or VMWare, running Linux PPC images on a Darwin box, or Linux Sparc images on a Solaris box - why limit this architecture purely to Microsoft? > Also, what are you planning on doing with graphic applications? CoLinux > works by running a X server on the windows machine. That's probably not > the best solution there is. How is the ReactOS windowing back-end > implemented? I'm more interested in running headless servers myself. If I *really* need a head, I have ssh tunnelled X11 or tight VNC sessions. To truely grasp the importance what CoLinux offers, think hugely scalable hosting farm. The closest thing to CoLinux at the moment is really the Xen Hypervisor: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ Unfortunately, Xen isn't cross architecture, and you need to retrofit other kernels to run under it (see the Windows XP port limited to academic source licensees, or the recent NetBSD port to the same). At the moment, UML is the hosting platform of choice for virtual Linux servers - but there are real speed and minor irritating stability issues. Xen has its own LVM like virtual disk system in 1.2 - there is only planned support for UBD style devices, and all domains must access the disk simultaneously. Both Plex86 and Fabrice Bellard's QEMU have slightly modified kernels that can run across platforms and virtualize kernels in a somewhat similar way (though on a simulated or vitualized system without a ring 0 driver hack). I would LOVE to have a Linux self-hosted, ring 0 device driver driven, generic virtual machine subsystem for Linux that does not require Jeff Dyke's user-space hacks to work (no offense intended toward Jeff Dyke's incredible accomplishments with UML). There are a suprising number of people quietly following this train of thought. The early adopters are already running farms of hundreds (soon to be thousands) of virtual machines in clustered Linux farms. If there were a way to run CoLinux on an OpenSSI Linux cluster right now, you better believe we would already be doing it. - Ian C. Blenke <ia...@bl...> |
|
From: Nuno S. <nun...@vg...> - 2004-01-31 05:18:28
|
Hi! Ian C. Blenke wrote: > On Thu, Jan 29, 2004 at 12:42:30AM +0200, Shachar Shemesh wrote: [..] > parallel with OTHER kernels. Think of Linux X86 images running on a > Linux X86 host without UML or VMWare, running Linux PPC images on a Darwin > box, or Linux Sparc images on a Solaris box - why limit this > architecture purely to Microsoft? > Agreed. [..] > > To truely grasp the importance what CoLinux offers, think hugely > scalable hosting farm. The closest thing to CoLinux at the moment is > really the Xen Hypervisor: > > http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ > > Unfortunately, Xen isn't cross architecture, and you need to retrofit > other kernels to run under it (see the Windows XP port limited to > academic source licensees, or the recent NetBSD port to the same). > > At the moment, UML is the hosting platform of choice for virtual Linux I can be wrong, but I think that coLinux doesn't play in this field (virtual servers for *untrusted* root users) because, unlike UML or XEN, the "virtual" linux can bring the host down. Disabling interrupts and entering and endless loop or /bin/cat /dev/random > /proc/kmem or some other havoc will do this... Reality check: I'm I right? Even with this possible drawback, the system is very usefull for running "trusted" linux systems at (near) hardware speed. > > I would LOVE to have a Linux self-hosted, ring 0 device driver driven, Me too :-) And, as you said, there are some solutions right now, each with their pro's and con's. Regards, Nuno Silva |
|
From: Ian C. B. <ia...@bl...> - 2004-01-31 06:14:37
|
On Thu, Jan 29, 2004 at 01:26:52AM +0000, Nuno Silva wrote: > >At the moment, UML is the hosting platform of choice for virtual Linux > > I can be wrong, but I think that coLinux doesn't play in this field > (virtual servers for *untrusted* root users) because, unlike UML or XEN, > the "virtual" linux can bring the host down. A UML may be run as a Honeypot. There really hasn't been talk of using Xen for the same on the list. Honestly, this isn't what I'm looking for. I'm not suggesting giving root to untrusted users for hosting purposes. Even with the fairsched kernel patch on a SKAS enabled host, users may still monopolize system resources with UML (namely system IO). It's actually easier to provision independant "virtual servers" in a virtual networked topology rather than pile layer after layer of complexity onto a single image. With separate IP stacks, you can intermix LVS servers and iptables firewall boxes between content hosting images and VMWare servers. We are doing this with UML and VMWare now, but the performance really could use some help (particularly when UML images become IO bound). > Disabling interrupts and entering and endless loop or /bin/cat > /dev/random > /proc/kmem or some other havoc will do this... In an ideal world, a virtual image would be sandboxed off from other images and the host kernel. From a management perspective, I would rather have a dozen "just as insecure" but separate images serving simplified purposes than one large complex system. You can always lock down and compartmentalize those insecure kernels using standard techniques. > Even with this possible drawback, the system is very usefull for running > "trusted" linux systems at (near) hardware speed. Precisely what I am looking for. > >I would LOVE to have a Linux self-hosted, ring 0 device driver driven, > > Me too :-) And, as you said, there are some solutions right now, each > with their pro's and con's. Getting a Linux/x86 native host port working would be a great first step. Is anyone actively working on this at the moment? I would love to help any way I can. - Ian C. Blenke <ia...@bl...> |
|
From: Karim Y. <ka...@op...> - 2004-01-31 08:40:32
|
Ian C. Blenke wrote: > Getting a Linux/x86 native host port working would be a great first > step. Is anyone actively working on this at the moment? I would love to > help any way I can. As I was saying on the LKML a few days ago, I've extensively researched this topic and have written a few papers explaining how this could be done using a nanokernel. One of the papers I wrote covers the use of such a nanokernel to easily obtain SMP-clusters with Linux. Much of what I cover in that paper can be reused as-is and simplified for a UP system. Currently there already exists the nanokernel code to share interrupts via a pipeline. What remains is code that can: - Allocate separate physical regions - Switch between the OS instances Dan's work already provides some of this and I'd be quite happy to see someone take this and extend the existing Adeos nanokernel in this direction. Here are some relevant URLs: http://www.opersys.com/adeos/index.html (the papers) http://www.adeos.org (the project's site) Some relevant LKML postings: http://marc.theaimsgroup.com/?l=linux-kernel&m=102309348817485&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=106273515411971&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=107509323428966&w=2 (forget the first paragraph of that last posting, Dan pointed out that I wasn't reading the coLinux code right in a later reply.) Basically, the idea is to change Linux the least possible while still being able to run multiple copies of it on the same machine. I think this is easily done for someone who has the time (I personally don't have the bandwidth). The greatest asset of the above approach is that it's practically hardware-independent and should therefore not be limited to x86. Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || ka...@op... || 1-866-677-4546 |
|
From: Dan A. <da...@gm...> - 2004-01-31 08:30:27
|
On Thu, Jan 29, 2004 at 01:26:52AM +0000, Nuno Silva wrote: > > I can be wrong, but I think that coLinux doesn't play in this field > (virtual servers for *untrusted* root users) because, unlike UML or XEN, > the "virtual" linux can bring the host down. > > Disabling interrupts and entering and endless loop or /bin/cat > /dev/random > /proc/kmem or some other havoc will do this... > > Reality check: > I'm I right? It is possible to take some measurements in coLinux that will allow it to crash peacefully without hurting the host OS. For example, on the first Oops, switch back to the host and shut it down. There are slims chances that memory corruption inside coLinux would hurt the host OS since all memory that is mapped inside coLinux is physical memory that was allocated specially for it. However, if you deliberately overwrite page tables in coLinux and cause them to map host physical memory that was unallocated for it *and* then corrupt that memory, it will bring down the host. Another way to do so is to specifically corrupt the passage page. Or as you said, you can upload a kernel module under coLinux which disables intrrupts and enters an endless loop. -- Dan Aloni da...@gm... |
|
From: Steven E. <ste...@ya...> - 2004-01-31 04:28:23
|
--- Shachar Shemesh <win...@sh...> wrote: > While it's certainly an exiting project, I understood that it was NOT > > based on the Windows subsystem mechanism, but rather hacking your way > > into Windows NT's ring 0 using a device driver. While I'm a great fan > of > "if it works", wouldn't it be nicer, long run, to have a proper > subsystem of it? As one of the other comments said the Windows POSIX subsystem model has some limitations. I would like to bring CoLinux to the point that it ties in as well to Windows and ReactOS as SFU does. > Also, what are you planning on doing with graphic applications? > CoLinux > works by running a X server on the windows machine. That's probably > not > the best solution there is. How is the ReactOS windowing back-end > implemented? We are looking at that currently. ReactOS's TCP/IP implemetation is lacking so running XFree/Cygwin is not a option atm. Once we get TCP/IP going than any Xserver for Windows should do but I would like to bring libw11 in to ReactOS and implement a Xserver as a core OS componate. LibW11 if you dont know about it sits on top of User32/GDI and translates all of the XLib calls to Win32 calls. I we can make a faster/lighter Xserver reusing this code. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ |
Thanks for helping keep SourceForge clean.
X