colinux-devel

[coLinux-devel] coLinux 0.6.0

[Dan A. <da...@co...>]

Hello, 

coLinux 0.6.0 is released.

This is the same as the 20040322 snapshot.

Stability on SMP / HT setups was not addressed yet, so beware.

The supplied vmlinux supports iso9660, reiserfs, and smbfs.

* Version 0.6.0 AKA "Getting even"
  * Ballard, Jonathan H.:  
    * fixed implicit declarations
    * added co_os_realloc()
    * fixed overflow with the XML memory config
    * reimplemented os/winnt/user/daemon.c.
      A threaded implementation with with message queue,
      wait state, and error recovery.
    * merged the NT-native console. 
    * console updates and improvements (cocon, console-nt)
    * update FLTK/console clearscreen (20040305)
    * enabled console-nt exit (20040305)
  * Added more checks to the XML parsing.
  * Made the context switch code more sensitive about the processor's 
    capabilities, running coLinux on old AMD processors will hopefully not 
    cause a reboot anymore.
  * Linux patch upgraded to 2.4.25.
  * Hopefully fixed the %fs/%gs issue for good.
  * vmlinux can now be bigger while not causing the host to boot, this means
    that you can compile more stuff not as modules.
  * Reimplemented the method in which coLinux allocates memory in the host
    kernel. It now allocates memory from the unmapped free page pool, which  
    means you can use more than 256MB of RAM, unlike the previous method. 
    Note that the first coLinux boot may be a little slower since Windows is 
    freeing cache and swapping out stuff in order to provide accommodation for 
    Linux's memory. You can see it in action by looking at the Task Manager.
  * NSIS-based installer for the Windows binary distribution (based on 
    work by NEBOR Regis.
  * gettimeofday() now works. Things that broke because they depended on it
    should now work. I have to enable port I/O in order to for this to work,
    but I plan to disable it in the future. If you compile a new vmlinux
    Make sure that CONFIG_X86_TSC is enabled in your .config file.
  * New daemon switch -t: Type of console to launch. Default is fltk.


-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] coLinux 0.6.0

[Paul S. <coo...@ua...>]

Hello Dan,

Thursday, March 25, 2004, 10:52:25 PM, you wrote:

DA> Hello, 

DA> coLinux 0.6.0 is released.

[]

  Thanks for this release! I would like to share my experiences with
it, hopefully adding some new information.

  My setup is p4-2.66(non-HT), MB SIS 651, 1Gb RAM, WinXP Home. My
interest with coLinux is to have good development/testing environment at
fingertips (including for such things as J2EE), so soon after playing
with this version I've set memsize to 256Mb (and so I cannot tell for
sure if issues below occur in any conf or due to such a "big"
memsize).

  So, generally it works quite well. One thing I noticed is that if I
run and stop coLinux several times, eventually it stops working -
it just hangs in initial startup messages or bails out. If hangs, it
can be ctrl+break'ed. Nothing bad (in terms of stability) seems to be
done to Windows. To be more precise, I have a very strong feeling that
this hanging-on-many-starts things happens if I suspended computer
inbetween - at least I couldn't reproduce this by just
running/stopping it several times in row.

  I didn't try to investigate above problem more simply because I
found that running coLinux handles suspend pretty well. For reference,
I'm using S3 suspend - all computer devices stop and it appears
powered off, but RAM retains information. With this setup, when I
un-suspend, coLinux puts "i8253 count too high! resetting.." and hangs
for about minute a so (totally unresponsive, telent connections drop).
But after that it recovers (usually see smb diagnostics messages) and
all's well.

  The overall stability and functioning is pretty good - I built some
pretty big J2EE app (JBoss/Tomcat, processes up to 170Mb in size,
etc.) and it seems to be ok (haven't done extensive testing yet
though). The real good news is performance - I yet have to do exact
comparisons with natively running Linux, but it's close enough
(nothing like VMware which times slower) and faster than the same app
builds in native Windows ;-) (and that's with more memory available).


-- 
Best regards,
 Paul                            mailto:coo...@ua...