You can subscribe to this list here.
2004 |
Jan
(64) |
Feb
(530) |
Mar
(266) |
Apr
(580) |
May
(360) |
Jun
(161) |
Jul
(185) |
Aug
(164) |
Sep
(123) |
Oct
(160) |
Nov
(59) |
Dec
(84) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(156) |
Feb
(95) |
Mar
(124) |
Apr
(81) |
May
(79) |
Jun
(179) |
Jul
(35) |
Aug
(64) |
Sep
(56) |
Oct
(57) |
Nov
(18) |
Dec
(41) |
2006 |
Jan
(65) |
Feb
(37) |
Mar
(59) |
Apr
(73) |
May
(65) |
Jun
(27) |
Jul
(54) |
Aug
(76) |
Sep
(103) |
Oct
(23) |
Nov
(45) |
Dec
(29) |
2007 |
Jan
(41) |
Feb
(47) |
Mar
(61) |
Apr
(24) |
May
(14) |
Jun
(6) |
Jul
(23) |
Aug
(30) |
Sep
(16) |
Oct
(9) |
Nov
(53) |
Dec
(36) |
2008 |
Jan
(19) |
Feb
(49) |
Mar
(74) |
Apr
(21) |
May
(24) |
Jun
(5) |
Jul
(9) |
Aug
(53) |
Sep
(26) |
Oct
(23) |
Nov
(32) |
Dec
(19) |
2009 |
Jan
(47) |
Feb
(49) |
Mar
(39) |
Apr
(61) |
May
(28) |
Jun
(19) |
Jul
(12) |
Aug
(10) |
Sep
(31) |
Oct
(16) |
Nov
(60) |
Dec
(26) |
2010 |
Jan
(17) |
Feb
(9) |
Mar
(32) |
Apr
(11) |
May
(24) |
Jun
(33) |
Jul
(5) |
Aug
(2) |
Sep
(7) |
Oct
(8) |
Nov
(17) |
Dec
(7) |
2011 |
Jan
(12) |
Feb
(16) |
Mar
(2) |
Apr
(12) |
May
(5) |
Jun
(10) |
Jul
(3) |
Aug
(3) |
Sep
(2) |
Oct
(1) |
Nov
(17) |
Dec
(1) |
2012 |
Jan
(9) |
Feb
(9) |
Mar
(8) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(11) |
Oct
(1) |
Nov
(2) |
Dec
(2) |
2013 |
Jan
|
Feb
(7) |
Mar
(4) |
Apr
(10) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(3) |
2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Dan A. <da...@gm...> - 2004-01-31 22:30:23
|
On Sat, Jan 31, 2004 at 10:23:25PM +0000, Tony Hoyle wrote: > I could see if I can run it in a debug/checked WinXP I guess, but if > this driver is as low level as it sounds that might not help. I disagree. Running in a debug/checked Windows XP might help to spot other issue, not only explaining this one. -- Dan Aloni da...@gm... |
From: Dan A. <da...@gm...> - 2004-01-31 22:26:40
|
On Sat, Jan 31, 2004 at 04:55:57PM -0500, Matt Behrens wrote: > Okay, it seems there are worse problems than just misreporting the > size in cobd. > > It seems in e2fslibs that the size is actually determined by an > algorithm I can't get my weekend brain around, but it does a lot > of seeking and trying to read a byte to get the "real" size. > > Armed with this idea I tried to dd if=/dev/cobd0 of=/dev/null bs=1k > count=128k (using my 128M image). I got a stream of I/O errors > near the end and DebugView is filled with several messages starting > with "block io failed: edbb6000 400 (reason: c0000011)". Goes up > to edea6c00. c0000011 is STATUS_END_OF_FILE. It is possible that reading cobd devices from userspace is broken. Prehaps in that scenario offsets are passed from Linux to Windows wrongly. > I can't find the above DebugView message anywhere in the 0.5.2 > colinux source I pulled today. It's in colinux/os/winnt/kernel/block.c. -- Dan Aloni da...@gm... |
From: ePAc <ep...@ko...> - 2004-01-31 22:25:23
|
> OK, that was different - it didn't work for me. I get a blue-screen when I > run the modified colinux-daemon.exe, due to: > > IRQL_NOT_LESS_OR_EQUAL > > Larry I got this as well, and i'm now waiting for the system to dump the whole memory. would any kind of processing on the memdump be useful to anyone ? the machine is a Dell Inspiron 5150, 1.6Ghz, P4, 512M ram, and enough HD to have a couple more full mem dumps... Let me know... Jok --- Nothing is foolproof to a sufficiently talented fool... oo ,(..)\ ~~ |
From: Tony H. <tm...@no...> - 2004-01-31 22:23:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Behrens wrote: | | Was this your first time? I got similar messages earlier when I | was playing around, but did not think to record them. The catch | was that I was trying to kill the first daemon and left myself | needing a reboot. This was straight after a boot. | Also, you are an Administrator? Yes. I could see if I can run it in a debug/checked WinXP I guess, but if this driver is as low level as it sounds that might not help. Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAHCrd5UdHDk9LaRcRAubNAJ0eyof8/rSqQ+XAvAW29+sIdrAjiACeO87N YakrkAOvC6RJI847WrHvpEA= =xs+Y -----END PGP SIGNATURE----- |
From: Dan A. <da...@gm...> - 2004-01-31 22:21:08
|
On Sat, Jan 31, 2004 at 10:02:39PM +0000, Tony Hoyle wrote: > On an XP Pro machine with (most of) the latest patches, even the > updated colinux-daemon doesn't work: > > D:\colinux>colinux-daemon > Cooperative Linux daemon > Manager is already running > Manager not initialized (0) > Removing driver leftover > Stopping driver service > Removing driver service > Installing kernel driver > Error installing kernel driver: -15 Did the daemon run before the run you sent above? It couldn't have reached 'Manager is already running' if it isn't so. It would be very interesting to know what it spitted out in the very first run. > I've installed the TAP driver and this comes up 'not connected', which I > assume is normal. The only things running are my normal bootup > configuration of XFree & sshd, plus sundry grapihics/sounds systray > things that seem to plague Windows so much. > > Running colinux-daemon a second time causes the system to reboot.. I > guess it's not cleaning up somewhere? Thanks for your feedback. I admit there are currently some stability issues concering the removal of the driver. I haven't completly addressed them, but I am planning to do so. -- Dan Aloni da...@gm... |
From: Dan A. <da...@gm...> - 2004-01-31 22:20:11
|
On Sat, Jan 31, 2004 at 05:12:52PM -0500, Matt Behrens wrote: > On Sat, Jan 31, 2004 at 10:02:39PM +0000, Tony Hoyle wrote: > > > On an XP Pro machine with (most of) the latest patches, even the > > updated colinux-daemon doesn't work: > > > > D:\colinux>colinux-daemon > > Cooperative Linux daemon > > Manager is already running > > Manager not initialized (0) > > Removing driver leftover > > Stopping driver service > > Removing driver service > > Installing kernel driver > > Error installing kernel driver: -15 > > Was this your first time? I got similar messages earlier when I > was playing around, but did not think to record them. The catch > was that I was trying to kill the first daemon and left myself > needing a reboot. Matt, killing the daemon forcefully yields unexpected results at this time. There is a need to avoid doing that. > Also, you are an Administrator? Right, that would have been worth mentioning in the README file I supplied. -- Dan Aloni da...@gm... |
From: Matt B. <ma...@zi...> - 2004-01-31 22:13:08
|
On Sat, Jan 31, 2004 at 10:02:39PM +0000, Tony Hoyle wrote: > On an XP Pro machine with (most of) the latest patches, even the > updated colinux-daemon doesn't work: >=20 > D:\colinux>colinux-daemon > Cooperative Linux daemon > Manager is already running > Manager not initialized (0) > Removing driver leftover > Stopping driver service > Removing driver service > Installing kernel driver > Error installing kernel driver: -15 Was this your first time? I got similar messages earlier when I was playing around, but did not think to record them. The catch was that I was trying to kill the first daemon and left myself needing a reboot. Also, you are an Administrator? > I've installed the TAP driver and this comes up 'not connected', which I > assume is normal. Yes, it is. It'll come up connected when the kernel boots. --=20 Matt Behrens <ma...@zi...> <http://www.zigg.com/> Life's too short to recompile what you don't hack. <http://www.debian.org/> |
From: Tony H. <tm...@no...> - 2004-01-31 22:03:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On an XP Pro machine with (most of) the latest patches, even the updated colinux-daemon doesn't work: D:\colinux>colinux-daemon Cooperative Linux daemon Manager is already running Manager not initialized (0) Removing driver leftover Stopping driver service Removing driver service Installing kernel driver Error installing kernel driver: -15 I've installed the TAP driver and this comes up 'not connected', which I assume is normal. The only things running are my normal bootup configuration of XFree & sshd, plus sundry grapihics/sounds systray things that seem to plague Windows so much. Running colinux-daemon a second time causes the system to reboot.. I guess it's not cleaning up somewhere? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAHCX/5UdHDk9LaRcRAhHbAJ4n81rQZZpfYzVMBjxcvlu7dR0ejgCfTIfU iCAeiqYOdOXnetJyMJumR8U= =VmI+ -----END PGP SIGNATURE----- |
From: Matt B. <ma...@zi...> - 2004-01-31 21:56:09
|
Okay, it seems there are worse problems than just misreporting the size in cobd. It seems in e2fslibs that the size is actually determined by an algorithm I can't get my weekend brain around, but it does a lot of seeking and trying to read a byte to get the "real" size. Armed with this idea I tried to dd if=3D/dev/cobd0 of=3D/dev/null bs=3D1k count=3D128k (using my 128M image). I got a stream of I/O errors near the end and DebugView is filled with several messages starting with "block io failed: edbb6000 400 (reason: c0000011)". Goes up to edea6c00. I can't find the above DebugView message anywhere in the 0.5.2 colinux source I pulled today. So I think I'm stuck for the day... hopefully someone smarter than me can pick it up from here. --=20 Matt Behrens <ma...@zi...> <http://www.zigg.com/> Life's too short to recompile what you don't hack. <http://www.debian.org/> |
From: <my...@gm...> - 2004-01-31 21:28:04
|
Well, its definitely repeatable on my machine! I'm using Windows XP-Pro on a Dell Inspiron 2650 Notebook, if that helps. I haven't done any Windows Kernel debugging before, but I'll see what I can come up with. Larry. > On Sat, Jan 31, 2004 at 04:32:01PM -0500, my...@gm... wrote: >> OK, that was different - it didn't work for me. I get a blue-screen when >> I >> run the modified colinux-daemon.exe, due to: >> >> IRQL_NOT_LESS_OR_EQUAL > > This is bug I'm haunting for awhile, but I haven't managed to reproduce > it with my computers. I'm not sure what causes this, but it is possible > that some hardware configurations are responsible. > > If you have some Windows kernel debugging experience or know anyone who > does and can help, please tell. > > -- > Dan Aloni > da...@gm... > |
From: Dan A. <da...@gm...> - 2004-01-31 21:19:49
|
On Sat, Jan 31, 2004 at 04:32:01PM -0500, my...@gm... wrote: > OK, that was different - it didn't work for me. I get a blue-screen when I > run the modified colinux-daemon.exe, due to: > > IRQL_NOT_LESS_OR_EQUAL This is bug I'm haunting for awhile, but I haven't managed to reproduce it with my computers. I'm not sure what causes this, but it is possible that some hardware configurations are responsible. If you have some Windows kernel debugging experience or know anyone who does and can help, please tell. -- Dan Aloni da...@gm... |
From: <my...@gm...> - 2004-01-31 21:11:51
|
OK, that was different - it didn't work for me. I get a blue-screen when I run the modified colinux-daemon.exe, due to: IRQL_NOT_LESS_OR_EQUAL Larry > On Sat, Jan 31, 2004 at 03:03:28PM -0500, my...@gm... wrote: >> First, thanks a bunch, Dan, for all of the hard work you've done. I'm >> looking forward for working with colinux, like many others who are >> following this project. >> >> I download and installed the binary files, per the instructions in the >> README. The TAP-Win32 driver seemed to install OK. When I try to run the >> colinux-daemon.exe program, I get "Error initializing the kernel driver" >> and it terminates with a "-1". FWIW, I'm running Windows-XP Pro. Any >> suggestions? > > Since more than one person saw this problem, I've compiled a slightly > modified colinux-daemon.exe and added it to the release. > > Now, for the source code part of this message: > > It appears that an error is wrongly propagated from kernel space > to user space when the driver gets initialized by the daemon. The branch > that gets affected is in co_manager_init() (colinux/user/manager.c). It > also appears that it doesn't happen on my setup. > > In the patched daemon, I changed co_manager_init() so that it would > always return CO_RC_OK. With this patch, it appears that the daemon > continues running on Matt's setup without other such failures. > > Since this is a developers mailing list, I urge you to look at the > source and send me a patch :) I mean, help me debug this faster. You do > want a working coLinux, right? ;). > > -- > Dan Aloni > da...@gm... > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Matt B. <ma...@zi...> - 2004-01-31 21:05:16
|
On Sat, Jan 31, 2004 at 10:46:56PM +0200, Dan Aloni wrote: > I need to see more of these reports to find out whether the 30448=20 > number that fsck prints there is fixed. I also saw this today. While=20 > trying to debug it, It sometimes occurs and sometime doesn't, and only=20 > with that image.=20 FWIW, I made a smaller image (128M) by loop-mounting both and moving the files over; I got the same message on boot, this time 121793 blocks vs. the correct figure of 131072. Curious -- can I infer that there are disk-style images that do work? --=20 Matt Behrens <ma...@zi...> <http://www.zigg.com/> Life's too short to recompile what you don't hack. <http://www.debian.org/> |
From: Dan A. <da...@gm...> - 2004-01-31 20:47:07
|
On Sat, Jan 31, 2004 at 03:06:57PM -0500, Matt Behrens wrote: > On Sat, Jan 31, 2004 at 09:58:29PM +0200, Dan Aloni wrote: > > > I attached a slightly modified version of the daemon. > > Okay, this one got me booted. However, now I see: Oh very good, now you can play with it ;) > /dev/cobd0: The filesystem size (according to the superblock) is 262144 blocks > The physical size of the device is 30448 blocks > 262144 sounds much more likely to me, given the gigabyte image I'm > mounting. It occured on my setup as well. I need to see more of these reports to find out whether the 30448 number that fsck prints there is fixed. I also saw this today. While trying to debug it, It sometimes occurs and sometime doesn't, and only with that image. I am going to look inside the fsck source code to get more clue. Perhaps it's a cobd bug, related to the way it answers to ioctl()s. Until it gets fixed, you can hack your way out of it if you edit that init script from inside coLinux. -- Dan Aloni da...@gm... |
From: Dan A. <da...@gm...> - 2004-01-31 20:32:37
|
On Sat, Jan 31, 2004 at 03:03:28PM -0500, my...@gm... wrote: > First, thanks a bunch, Dan, for all of the hard work you've done. I'm > looking forward for working with colinux, like many others who are > following this project. > > I download and installed the binary files, per the instructions in the > README. The TAP-Win32 driver seemed to install OK. When I try to run the > colinux-daemon.exe program, I get "Error initializing the kernel driver" > and it terminates with a "-1". FWIW, I'm running Windows-XP Pro. Any > suggestions? Since more than one person saw this problem, I've compiled a slightly modified colinux-daemon.exe and added it to the release. Now, for the source code part of this message: It appears that an error is wrongly propagated from kernel space to user space when the driver gets initialized by the daemon. The branch that gets affected is in co_manager_init() (colinux/user/manager.c). It also appears that it doesn't happen on my setup. In the patched daemon, I changed co_manager_init() so that it would always return CO_RC_OK. With this patch, it appears that the daemon continues running on Matt's setup without other such failures. Since this is a developers mailing list, I urge you to look at the source and send me a patch :) I mean, help me debug this faster. You do want a working coLinux, right? ;). -- Dan Aloni da...@gm... |
From: Dan A. <da...@gm...> - 2004-01-31 19:53:45
|
On Sat, Jan 31, 2004 at 02:39:36PM -0500, Matt Behrens wrote: > Result: > > C:\coLinux>colinux-daemon.exe > Cooperative Linux daemon > Installing kernel driver > Error initializing kernel driver > Removing kernel driver > Stopping driver service > Removing driver service > Daemon failed: -1 > > C:\coLinux> > > Any hints as to increasing verbosity etc. would be much appreciated. > All files are as the README asks them to be, and I am a "Computer > Administrator" in XP Home's user panel (which is significantly > suckier than 2000's, or I gather XP Pro's.) Can you please send me the output of DebugView http://www.sysinternals.com/files/dbgvnt.zip (Make sure that it captures kernel debug messages) Thanks, -- Dan Aloni da...@gm... |
From: <my...@gm...> - 2004-01-31 19:43:19
|
First, thanks a bunch, Dan, for all of the hard work you've done. I'm looking forward for working with colinux, like many others who are following this project. I download and installed the binary files, per the instructions in the README. The TAP-Win32 driver seemed to install OK. When I try to run the colinux-daemon.exe program, I get "Error initializing the kernel driver" and it terminates with a "-1". FWIW, I'm running Windows-XP Pro. Any suggestions? Thanks, Larry. |
From: Matt B. <ma...@zi...> - 2004-01-31 19:39:50
|
Tried to fire up coLinux on my XP Home Edition SP1a + current critical patches installation. (Hey, I wasn't going to plunk down the money for a better version of an OS I wasn't going to use on this laptop.) ;-) TAP-Win32 installed fine, though the procedure appears markedly different under Home. But it is there in the network connections, though it's marked with a red X because it's "down", which I assume is media status. Result: C:\coLinux>colinux-daemon.exe Cooperative Linux daemon Installing kernel driver Error initializing kernel driver Removing kernel driver Stopping driver service Removing driver service Daemon failed: -1 C:\coLinux> Any hints as to increasing verbosity etc. would be much appreciated. All files are as the README asks them to be, and I am a "Computer Administrator" in XP Home's user panel (which is significantly suckier than 2000's, or I gather XP Pro's.) My immediate suspicion is that XP Home isn't gonna fly. I may try to borrow my wife's 2000 laptop later on to test. --=20 Matt Behrens <ma...@zi...> <http://www.zigg.com/> Life's too short to recompile what you don't hack. <http://www.debian.org/> |
From: Dan A. <da...@gm...> - 2004-01-31 19:27:09
|
On Thu, Jan 29, 2004 at 07:14:08PM +1000, Ian Latter wrote: > > Thanks for putting that root filesystem online. From that > system, the new devices look like this; > > 0 brw-r--r-- 1 root 117, 0 Jan 28 08:57 cobd0 > 0 brw-r--r-- 1 root 117, 1 Jan 28 08:57 cobd1 > 0 brw-r--r-- 1 root 117, 2 Jan 28 08:57 cobd2 > 0 brw-r--r-- 1 root 117, 3 Jan 28 08:57 cobd3 > > > Are these the only ones I need? Looks straight-forward > so far ... Yes, these are the only device nodes that are added. -- Dan Aloni da...@gm... |
From: Ian L. <Ian...@mq...> - 2004-01-31 19:18:09
|
Thanks for putting that root filesystem online. From that system, the new devices look like this; 0 brw-r--r-- 1 root 117, 0 Jan 28 08:57 cobd0 0 brw-r--r-- 1 root 117, 1 Jan 28 08:57 cobd1 0 brw-r--r-- 1 root 117, 2 Jan 28 08:57 cobd2 0 brw-r--r-- 1 root 117, 3 Jan 28 08:57 cobd3 Are these the only ones I need? Looks straight-forward so far ... -- Ian Latter Internet and Networking Security Officer Macquarie University Meet me at the Australian Unix and open systems User Group (AUUG) Security Symposium; 2004 http://www.auug.org.au/events/2004/security/ |
From: Dan A. <da...@gm...> - 2004-01-31 18:52:01
|
Good evening, I just released version 0.5.2 of Cooperative Linux. This release include a binary snapshot FOR TESTING PURPOSES, although it can actully be used to run a stable Linux system on your Windows setups, considering it doesn't crash ;) Please read the included README file before running. Changes: * Added some missing files to the build tree * doc/cygwin-cross-build - How to build a cygwin cross compilation tools on Linux. * Made the daemon more proofed to mistakes. It's logic about loading/ unloading the driver is much more sane now. * Added a cursor support to the console. Good luck, -- Dan Aloni da...@gm... |
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:38:51
|
On Thu, Jan 29, 2004 at 11:00:22AM +1000, Ian Latter wrote: > > > Hello Dan, > > > Primarily, the requirement is creating a root block file system (using > > the loopback block device), while changing the disto to use newly added > > devices nodes /dev (cobd0, cobd1, etc...) instead of the /dev/hd* nodes. > > > > The closest examples for this now are the file system images distributed > > with User Mode Linux. However, these images sometimes miss the /dev/console > > node which causes the init process to fail (this also happens with the > > regular non-UML Linux kernel). Creating that node fixes the problem. > > I've just whipped thru the docs again; is there any info on the devices > and their numbering. Are they literally the same as the UML distros? The cooperative device drivers that I wrote, cobd, conet, and cocon are not designed to be the same like the ones you find in the UML distros. cobd and ubd don't even have the same major number. BTW, I've uploaded to sourceforge a root file system that can be used for booting a system under coLinux. It extracts to a 1GB basic debian system that allows you to run 'apt-get' in order to get more packaages. > > Yesterday I was under the impression that the binaries are stable enough > > to be released. I hope to release some example binaries soon, so you > > and the others can experiment with it. > > This would be good. I have never had to build a CYGWIN dev > environment .. this would save a lot of time - methinks. Would the > binary bits be GPL? Yes, all the binary code that I am going to upload today is directly compiled from the tarball source that will be released along. coLinux is entirely under GPL. -- Dan Aloni da...@gm... |
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: Ian L. <Ian...@mq...> - 2004-01-31 07:28:44
|
Hello Favre, I've read and re-read your message, and I don't think you meant what you said. ClusterKNOPPIX runs openMosix, not Mosix. I don't think it ever ran Mosix - it may have. If I'm right about the openMosix vs Mosix thing, and you're only looking for a binary distribution that you can run on your work- stations, then you should be right to run CHAOS when I've gotten this to work. If all goes well (and IPSEC seems to be patching in ok at this stage) .. then you will be able to download CHAOS and install that on your workstations ... hopefully. ----- Original Message ----- >From: "Favre Benoit" <ben...@li...> >To: <col...@li...> >Subject: [coLinux-devel] coLinux and Mosix ? >Date: Wed, 28 Jan 2004 14:50:36 +0100 > > hello, > do you think that the MOSIX kernel patch would work with coLinux. > > I work in a university where thousands of windows computers are unused during > night and hollyday time. A "screensaver" version of coLinux with MOSIX > support could lead to great supercomputing clusters with a very simple > deployment (i currently use clusterknoppix, the mosix/knoppix distribution > but it implies a machine reboot). > > regards, > -- > Benoit Favre > tel: +33 (0)6 63 20 02 14 > +33 (0)4 90 84 35 77 > mail: ben...@li... > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > -- Ian Latter Internet and Networking Security Officer Macquarie University Meet me at the Australian Unix and open systems User Group (AUUG) Security Symposium; 2004 http://www.auug.org.au/events/2004/security/ |