From: Philippe S. <phi...@si...> - 2006-07-31 09:13:53
|
Hi @ll, I'm trying to build coLinux (0.6.4) for running it on a Linux host (Debian Sarge | Kernel: 2.6.17.6-vanilla PREEMPT). For=20 coLinux I've got an root filesystem (LFS with Init from Busybox and 2.6.11.12-coLinux-vanilla as kernel), with runs fine on a Windows OS. The Wiki page[1] didn't help me :-(. [1] http://wiki.colinux.org/mediawiki/index.php/CoLinux_on_Linux What have I done? (1) Installing tofrodos package for getting unix2dos command on my host maschine and changing the coLinux configure script for getting unix2dos version (-:. (2) Changing my version.h (from my host vanilla kernel) and correct "HOST_EXTRAVERSION" to "HOST_EXTRAVERSION=3D.6-vanilla". (3) Running the coLinux configure script: # ./configure --target=3Di686-pc-linux --downloaddir=3D/tmp --targetkern= eldir=3D/tmp/linux-2.6.11 --hostkerneldir=3D/usr/src/linux target_cpu=3Di686 target_vendor=3Dpc target_os=3Dlinux Setting colinux_os=3Dlinux Setting prefix=3D/usr/src/linux Setting distdir=3D/usr/src/linux/dist colinux_version=3D0.6.4 target_kernel_dir=3Dv2.6 target_kernel_version=3D2.6.11 Setting targetkerneldir=3D/tmp/linux-2.6.11 UNAME_RELEASE=3D2.6.17.6-vanilla HOST_VERSION=3D2 HOST_PATCHLEVEL=3D6 HOST_SUBLEVEL=3D17 HOST_EXTRAVERSION=3D.6-vanilla Setting logfile=3D/usr/src/log/build-colinux-$$.log Checking for wget ... found Checking for Python interpreter ... found Checking for patch ... found Checking for make ... found Checking for binutils host ... (2.15.0) found Checking for gcc host ... (3.4.4) found Checking for gcc g++ ... (3.4.4) found Checking for FLTK devel (patched) ... (1.1.6) found Checking for mxml devel ... found Create toplevel Makefile Create bin/user-build.cfg Configure DONE Ready for "make download && make && make install" (4) Running "make" can't find cooperative.h: # make make[1]: Entering directory `/usr/src/coLinux-0.6.4/src' g++ -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/user/console/widget.o` -g -DCOLINUX -DCOLINUX_ARC= H=3Dlinux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-s= trict-aliasing -Wall -DCOLINUX_DEBUG -O2 -I. -I/tmp/linux-2.6.11/inclu= de -c colinux/user/console/widget.cpp -o colinux/user/console/widget.o In file included from ./colinux/common/console.h:13, from colinux/user/console/widget.h:20, from colinux/user/console/widget.cpp:13: ./colinux/common/common.h:28:31: linux/cooperative.h: No such file or dir= ectory In file included from colinux/user/console/widget.h:20, from colinux/user/console/widget.cpp:13: ./colinux/common/console.h:51: error: `co_cursor_pos_t' does not name a t= ype ./colinux/common/console.h:58: error: `co_console_message_t' has not been= declared ./colinux/common/console.h:58: error: ISO C++ forbids declaration of `mes= sage' with no type In file included from colinux/user/console/widget.cpp:13: colinux/user/console/widget.h:30: error: `co_console_message_t' has not b= een declared colinux/user/console/widget.h:30: error: ISO C++ forbids declaration of `= message' with no type colinux/user/console/widget.cpp: In member function `void console_widget_= t::blink_handler()': colinux/user/console/widget.cpp:51: error: 'struct co_console' has no mem= ber named 'cursor' colinux/user/console/widget.cpp:51: error: 'struct co_console' has no mem= ber named 'cursor' colinux/user/console/widget.cpp: In member function `virtual void console= _widget_t::draw()': colinux/user/console/widget.cpp:200: error: 'struct co_console' has no me= mber named 'cursor' colinux/user/console/widget.cpp:201: error: 'struct co_console' has no me= mber named 'cursor' colinux/user/console/widget.cpp:201: error: 'struct co_console' has no me= mber named 'cursor' colinux/user/console/widget.cpp:203: error: 'struct co_console' has no me= mber named 'cursor' colinux/user/console/widget.cpp:204: error: 'struct co_console' has no me= mber named 'cursor' colinux/user/console/widget.cpp:205: error: 'struct co_console' has no me= mber named 'cursor' colinux/user/console/widget.cpp:207: error: 'struct co_console' has no me= mber named 'cursor' colinux/user/console/widget.cpp: At global scope: colinux/user/console/widget.cpp:228: error: `co_rc_t console_widget_t::ha= ndle_console_event' is not a static member of `class console_widget_t' colinux/user/console/widget.cpp:228: error: `co_console_message_t' was no= t declared in this scope colinux/user/console/widget.cpp:228: error: `message' was not declared in= this scope colinux/user/console/widget.cpp:229: error: expected `,' or `;' before '{= ' token make[1]: *** [colinux/user/console/widget.o] Error 1 make[1]: Leaving directory `/usr/src/coLinux-0.6.4/src' make: *** [colinux] Error 2 I think, this problem containing the lack of the target kernel=20 (--targetkerneldir=3D/tmp/linux-2.6.11). Must I configure, patch and build this target kernel before??? Best regards, Philippe --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Philippe S. <phi...@si...> - 2006-07-31 10:19:37
|
* Stellwag, Philippe <phi...@si...> wrote: >=20 > (4) Running "make" can't find cooperative.h: Okay, I've found that I had to configure and compile my guest kernel, to get this header file (-:. Further more, I patched FLTK (1.1.4). I also made some softlinks in ...coLinux-0.6.4/src [CUT] lrwxrwxrwx 1 user users 36 Jul 31 11:25 asm -> /usr/src/linux-2.6.11.12= /include/asm lrwxrwxrwx 1 user users 39 Jul 31 11:23 linux -> /usr/src/linux-2.6.11.= 12/include/linux/ [/CUT] But now, there is another problem to compile coLinux for Linux hosts: [CUT] user@linux:/usr/src/coLinux-0.6.4$ make make[1]: Entering directory `/usr/src/coLinux-0.6.4/src' g++ -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/user/console/widget.o` -g -DCOLINUX -DCOLINUX_ARC= H=3Dlinux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-s= trict-aliasing -Wall -DCOLINUX_DEBUG -O2 -I. -I/tmp/linux-2.6.11/inclu= de -c colinux/user/console/widget.cpp -o colinux/user/console/widget.o g++ -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/user/console/main.o` -g -DCOLINUX -DCOLINUX_ARCH=3D= linux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-stric= t-aliasing -Wall -DCOLINUX_DEBUG -O2 -I. -I/tmp/linux-2.6.11/include = -c colinux/user/console/main.cpp -o colinux/user/console/main.o g++ -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/user/console/console.o` -g -DCOLINUX -DCOLINUX_AR= CH=3Dlinux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-= strict-aliasing -Wall -DCOLINUX_DEBUG -O2 -I.-I/tmp/linux-2.6.11/inclu= de -c colinux/user/console/console.cpp -o colinux/user/console/console.o g++ -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/user/console/select_monitor.o` -g -DCOLINUX -DCOL= INUX_ARCH=3Dlinux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraph= s -fno-strict-aliasing -Wall -DCOLINUX_DEBUG -O2 -I. -I/tmp/linux-2.6.= 11/include -c colinux/user/console/select_monitor.cpp -o colinux/user/co= nsole/select_monitor.o g++ -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/user/console/about.o` -g -DCOLINUX -DCOLINUX_ARCH= =3Dlinux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-st= rict-aliasing -Wall -DCOLINUX_DEBUG -O2 -I. -I/tmp/linux-2.6.11/includ= e -c colinux/user/console/about.cpp -o colinux/user/console/about.o ld -g -r -o colinux/user/console/user-console.o colinux/user/console/widg= et.o colinux/user/console/main.o colinux/user/console/console.o colinux/u= ser/console/select_monitor.o colinux/user/console/about.o [...] ln -s libc.c colinux/common/libc_strtol.c gcc -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/common/libc_strtol.o` -DCOLINUX -DCOLINUX_ARCH=3D= linux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-stric= t-aliasing -Wall -DCOLINUX_DEBUG -O2 -D__KERNEL__ -DCO_KERNEL -DCO_HOST= _KERNEL -g -I. -I/tmp/linux-2.6.11/include -DCO_LIBC__STRTOL -ccolinux/co= mmon/libc_strtol.c -o colinux/common/libc_strtol.o gcc -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/common/snprintf.o` -DCOLINUX -DCOLINUX_ARCH=3Dlin= ux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-strict-a= liasing -Wall -DCOLINUX_DEBUG -O2 -D__KERNEL__-DCO_KERNEL -DCO_HOST_KER= NEL -g -I. -I/tmp/linux-2.6.11/include -c colinux/common/snprintf.c -o c= olinux/common/snprintf.o cat colinux/common/files_list.txt | python colinux/common/file_ids.py > c= olinux/common/file_ids.c gcc -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/common/file_ids.o` -DCOLINUX -DCOLINUX_ARCH=3Dlin= ux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-strict-a= liasing -Wall -DCOLINUX_DEBUG -O2 -D__KERNEL__-DCO_KERNEL -DCO_HOST_KER= NEL -g -I. -I/tmp/linux-2.6.11/include -c colinux/common/file_ids.c -o c= olinux/common/file_ids.o gcc -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/common/unicode.o` -DCOLINUX -DCOLINUX_ARCH=3Dlinu= x -mpush-args -mno-accumulate-outgoing-args -Wno-trigraphs -fno-strict-al= iasing -Wall -DCOLINUX_DEBUG -O2 -D__KERNEL__ -DCO_KERNEL -DCO_HOST_KER= NEL -g -I. -I/tmp/linux-2.6.11/include -c colinux/common/unicode.c -o co= linux/common/unicode.o ar cr colinux/common/common.a colinux/common/queue.o colinux/common/conso= le.o colinux/common/debug.o colinux/common/errors.o colinux/common/messag= es.o colinux/common/version.ocolinux/common/libc.o colinux/common/libc_st= rtol.o colinux/common/snprintf.o colinux/common/file_ids.o colinux/common= /unicode.o g++ colinux/user/console/user-console.o colinux/os/current/user/console/h= ead.o colinux/user/user.a colinux/os/current/user/user.a colinux/common/c= ommon.a -o colinux/os/current/user/console/colinux-console-fltk -lmxml -L= /usr/local/lib -L/usr/X11R6/lib -lfltk -lm -lXext -lX11 -lsupc++ gcc -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/os/current/user/daemon/main.o` -g -DCOLINUX -DCOL= INUX_ARCH=3Dlinux -mpush-args -mno-accumulate-outgoing-args -Wno-trigraph= s -fno-strict-aliasing -Wall -DCOLINUX_DEBUG -O2 -I. -I/tmp/linux-2.6.= 11/include -c colinux/os/current/user/daemon/main.c -o colinux/os/curren= t/user/daemon/main.o -DCO_HOST_API gcc -DCOLINUX_FILE_ID=3D`python ../bin/file_id.py create ./colinux/common= /files_list.txt colinux/os/current/user/daemon/debug.o` -g -DCOLINUX -DCO= LINUX_ARCH=3Dlinux -mpush-args -mno-accumulate-outgoing-args -Wno-trigrap= hs -fno-strict-aliasing -Wall -DCOLINUX_DEBUG -O2 -I. -I/tmp/linux-2.6= .11/include -c colinux/os/current/user/daemon/debug.c -o colinux/os/curr= ent/user/daemon/debug.o -DCO_HOST_API gcc colinux/os/current/user/daemon/main.o colinux/os/current/user/daemon/= debug.o colinux/user/user.a colinux/os/current/user/user.a colinux/common= /common.a -o colinux/os/current/user/daemon/colinux-daemon -lmxml colinux/user/user.a(config.o)(.text+0x1e0): In function `co_load_config_b= lockdev': colinux/user/config.c:166: undefined reference to `stricmp' colinux/user/user.a(config.o)(.text+0xfcd): In function `co_load_config': colinux/user/config.c:96: undefined reference to `stricmp' colinux/user/user.a(config.o)(.text+0x14cf): In function `co_parse_config= _args': colinux/user/config.c:506: undefined reference to `stricmp' colinux/user/user.a(config.o)(.text+0x1a0f):colinux/user/config.c:862: un= defined reference to `stricmp' collect2: ld returned 1 exit status make[1]: *** [colinux/os/current/user/daemon/colinux-daemon] Error 1 make[1]: Leaving directory `/usr/src/coLinux-0.6.4/src' make: *** [colinux] Error 2 [/CUT] Wtf??? Function "stricmp" undefined, why??? And how can I fix it??? Thanks!=20 Best regards, Philippe --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-07-31 10:50:22
|
Philippe Stellwag wrote: > * Stellwag, Philippe <phi...@si...> wrote: >> (4) Running "make" can't find cooperative.h: > > Okay, I've found that I had to configure and compile my guest > kernel, to get this header file (-:. Further more, I patched > FLTK (1.1.4). > > I also made some softlinks in ...coLinux-0.6.4/src > > [CUT] > lrwxrwxrwx 1 user users 36 Jul 31 11:25 asm -> /usr/src/linux-2.6.11.12/include/asm > lrwxrwxrwx 1 user users 39 Jul 31 11:23 linux -> /usr/src/linux-2.6.11.12/include/linux/ > [/CUT] Strong. You normal not need this. > But now, there is another problem to compile coLinux for Linux > hosts: > > [...] > Wtf??? Function "stricmp" undefined, why??? And how can I fix it??? I'm not shure about clean build for Linux as host under all compilers. Replace the stricmp with strcasecmp, and check the indlude strings.h. I'm remember me, tis was in devel branch 0.7.1 to. -- Henry Nestler |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-07-31 11:59:14
|
Philippe Stellwag schrieb: > * Henry Nestler <Henry.Ne@Arcor.de> wrote: >> The last usable kernel version is 2.6.12, that exist in the devel >> version of coLinux. > > Do you talking about the host kernel? > > Hmmm, sounds logical ;-). No, the target (coLinux) kernel. >>> (2) Changing my version.h (from my host vanilla kernel) and >>> correct "HOST_EXTRAVERSION" to "HOST_EXTRAVERSION=.6-vanilla". >> That's wrong. You should not do this on target kernel. The kernel >> patch from coLinux source does it. > > No, I did this on my host kernel: > > HOST_KERNEL=2.6.17.6 That is ok. This version you see with 'uname -r' The latest tested host kernel was 2.6.16-rc5, see file NEWS in coLinux source. Not all host kernels works. About 2.6.17 I'm not know. If the module colinux.ko give you an error (kernel oops), then try a tested host kernel version. > TARGET_KERNEL=2.6.11.12 (now patched, configured and compiled) The patch from coLinux (file patch/linux) was for kernel 2.6.11. If it was clean patched in 2.6.11.12, then should work. > Okay, the HOST_KERNEL must be 2.6.11.12 ?! No. -- Henry Nestler |
From: Philippe S. <phi...@si...> - 2006-07-31 12:33:53
|
* Henry Nestler <Henry.Ne@Arcor.de> wrote: > * Philippe Stellwag <phi...@si...>: >=20 > The latest tested host kernel was 2.6.16-rc5, see file NEWS in coLinux=20 > source. Not all host kernels works. About 2.6.17 I'm not know. If th= e=20 > module colinux.ko give you an error (kernel oops), then try a tested=20 > host kernel version. >=20 > > TARGET_KERNEL=3D2.6.11.12 (now patched, configured and compiled) >=20 > The patch from coLinux (file patch/linux) was for kernel 2.6.11. If it= =20 > was clean patched in 2.6.11.12, then should work. Yes, subversion .12 works fine - I've tested it on my Windows XP maschine and it works with LFS and Init from Busybox, I mentioned. > also made some softlinks in ...coLinux-0.6.4/src > > > > [CUT] > > lrwxrwxrwx 1 user users 36 Jul 31 11:25 asm -> > > /usr/src/linux-2.6.11.12/include/asm > > lrwxrwxrwx 1 user users 39 Jul 31 11:23 linux -> > > /usr/src/linux-2.6.11.12/include/linux/ > > [/CUT] > > Strong. You normal not need this. Without this symlinks it doesn't compile. I've tried it twise. > > But now, there is another problem to compile coLinux for Linux > > hosts: > > > > [...] > > Wtf??? Function "stricmp" undefined, why??? And how can I fix > > it??? > > I'm not shure about clean build for Linux as host under all > compilers. Replace the stricmp with strcasecmp, and check the indlude > strings.h. I'm remember me, tis was in devel branch 0.7.1 to. Doing ":%s/stricmp/strcasecmp/g" for .../src/colinux/user/config.c=20 and it works fine :-). Perfect!=20 HOST-conf: Debian Sarge with 2.6.17.6-vanilla PREEMPT =20 TARGET-conf: LFS with patched 2.6.11.12-colinux-vanilla Thanks a lot! Philippe --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Philippe S. <phi...@si...> - 2006-07-31 14:08:45
|
* Stellwag, Philippe <phi...@si...> wrote: >=20 > Doing ":%s/stricmp/strcasecmp/g" for .../src/colinux/user/config.c=20 > and it works fine :-). Perfect!=20 >=20 > HOST-conf: > Debian Sarge with 2.6.17.6-vanilla PREEMPT > =20 > TARGET-conf: > LFS with patched 2.6.11.12-colinux-vanilla Is there a special configuration syntax on coLinux 0.6.4 running on a Linux host? Esp. path names??? root@linux:~/coLinux# colinux-daemon kernel=3Dvmlinux cobd0=3Droot_fs \ cobd1=3Dswap_512Mb mem=3D160M root=3D/dev/cobd0 Works fine! But... [CUT=3Ddefault.colinux.xml] <?xml version=3D"1.0" encoding=3D"UTF-8"?> <colinux> <block_device index=3D"0"=20 path=3D"\DosDevices\root\coLinux\root_fs" enabled=3D"true" /> <block_device index=3D"1"=20 path=3D"\DosDevices\root\coLinux\swap_512Mb" enabled=3D"true" /> <cofs_device index=3D"0" type=3D"flat" path=3D"\DosDevices\root\"=20 enabled=3D"true" /> <bootparams>root=3D/dev/cobd0 mem=3D160M</bootparams> <!-- initrd path=3D"initrd.gz" / --> <image path=3D"vmlinux" /> <memory size=3D"160" /> <network index=3D"0" type=3D"tap" /> </colinux> [/CUT] root@linux:~/coLinux# colinux-daemon -c default.colinux.xml causes following error: [ERROR] [...] VFS: Cannot open root device "cobd0" or unknown-block(117,0) Please append a correct "root=3D" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on=20 unknown-block(117,0) [/ERROR] Adding "cobd0=3Droot_fs" to <bootparams>-tag making the same error.=20 Also substitute "\" to "/" doesn't help. I think colinux-daemon doesn't find the root-image "root_fs", but=20 what to do? Regards, Philippe --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Philippe S. <phi...@si...> - 2006-07-31 14:27:04
|
* Stellwag, Philippe <phi...@si...> wrote: >=20 > [...] > <block_device index=3D"0" path=3D"root_fs" enabled=3D"true" /> > <block_device index=3D"1" path=3D"swap_512Mb" enabled=3D"true" /> > [...] Okay, without pathnames it works (see above). But COFS doesn't want to work... Is there no COFS for coLinux with Linux host? Regards, Philippe P. S.: My subjective feeling says ;-) that coLinux is a little bit faster on Linux hosts -- could that be?! --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-07-31 16:51:57
|
Philippe Stellwag wrote: > * Stellwag, Philippe <phi...@si...> wrote: >> [...] >> <block_device index="0" path="root_fs" enabled="true" /> >> <block_device index="1" path="swap_512Mb" enabled="true" /> >> [...] > > Okay, without pathnames it works (see above). Right. You should use Linux path names. ;-) > But COFS doesn't > want to work... > > Is there no COFS for coLinux with Linux host? Cofs is not supported. > P. S.: My subjective feeling says ;-) that coLinux is a little > bit faster on Linux hosts -- could that be?! Yes, it is. The shedule for pipes is a liddle better, as under windows. I think, the time-overhead between processes is shorter. -- Henry Nestler |
From: Philippe S. <phi...@si...> - 2006-08-01 07:46:50
|
Good morning Henry! * Henry Nestler <Henry.Ne@Arcor.de> wrote: > Philippe Stellwag wrote: > > * Stellwag, Philippe <phi...@si...> wrote: > > > > [...] > > > <block_device index=3D"0" path=3D"root_fs" enabled=3D"true" /> > > > <block_device index=3D"1" path=3D"swap_512Mb" enabled=3D"true" /> > > > [...] > >=20 > > Okay, without pathnames it works (see above).=20 >=20 > Right. You should use Linux path names. ;-) Hell, yes -- Linux path names are better stuff as this windows syntax ^^. > > But COFS doesn't > > want to work... > >=20 > > Is there no COFS for coLinux with Linux host? >=20 > Cofs is not supported. By the way, it's better to use s/smbfs/cifs/g or NFS (for coLinux with Linux host). COFS it's a little bit buggy and only good for sharing file between the host- and guest-system without modify these. It's always not a good idea to mount one block device twice :-). But COFS is easy to use ^^. IMHO the problem of COFS is the different caching of the filesystem compared to linux and windows. Changes of files on COFS share (from coLinux side) are later seen on windows. So mostly of such modified file are broken-down, esp. you use this file on windows too. > > P. S.: My subjective feeling says ;-) that coLinux is a little > > bit faster on Linux hosts -- could that be?! >=20 > Yes, it is. The shedule for pipes is a liddle better, as under windows= .=20 > I think, the time-overhead between processes is shorter. I've tested it, it is really faster -- not only a little bit (-;. coLinux (Windows host) 0.6.4 losing 14,78 % of performance=20 compared to native linux compilering (tested with doxygen 1.4.7). coLinux (Linux host) 0.6.4 only loses 2,43 % compared to native linux compilering doxygen. That's really fast. VMware eat more than 25 % ^^. Best regards, Philippe --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-01 08:01:11
|
Hello Philippe, Philippe Stellwag wrote: >>> Is there no COFS for coLinux with Linux host? >> Cofs is not supported. > > By the way, it's better to use s/smbfs/cifs/g or NFS (for > coLinux with Linux host). COFS it's a little bit buggy and only > good for sharing file between the host- and guest-system without > modify these. It's always not a good idea to mount one block > device twice :-). But COFS is easy to use ^^. > > IMHO the problem of COFS is the different caching of the filesystem > compared to linux and windows. Changes of files on COFS share > (from coLinux side) are later seen on windows. So mostly of such > modified file are broken-down, esp. you use this file on windows > too. This should no do any problems. If you open a file under coLinux, this file is exclusive open under windows, and no other windows programs can access to that file. This is currently a small other problem, becaue coLinux self can't access the same file in short time after close. Colinux with linux as host is more for development the colinux code, not for practical use. I think. In this case UML is the better thing. -- Henry Nestler |
From: Philippe S. <phi...@si...> - 2006-08-01 08:51:43
|
* Henry Nestler <Henry.Ne@Arcor.de> wrote: > * Philippe Stellwag wrote: > >=20 > > [...] > >=20 > > IMHO the problem of COFS is the different caching of the filesystem > > compared to linux and windows. Changes of files on COFS share > > (from coLinux side) are later seen on windows. So mostly of such > > modified file are broken-down, esp. you use this file on windows > > too. >=20 > This should no do any problems. If you open a file under coLinux, this= =20 > file is exclusive open under windows, and no other windows programs can= =20 > access to that file. This is currently a small other problem, becaue=20 > coLinux self can't access the same file in short time after close. >=20 > Colinux with linux as host is more for development the colinux code, no= t=20 > for practical use. I think. In this case UML is the better thing. Partly there isn't any chance to write/modify a file within coLinux on a COFS share :-(. VIM say sometimes that fsync() fails. If on coLinux done modifications seen on Windows, they are never completely and valid! (Only tested with 0.6.{3,4}!!!) _Windows_ bad e_X__P_erience _S_tu_P_id _2_ :-) Best regards, Philippe --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Bernd B. <bb...@fr...> - 2006-08-02 17:14:55
|
On Tuesday 01 August 2006 09:46, Philippe Stellwag wrote: > I've tested it, it is really faster -- not only a little bit > (-;. coLinux (Windows host) 0.6.4 losing 14,78 % of performance > compared to native linux compilering (tested with doxygen > 1.4.7). coLinux (Linux host) 0.6.4 only loses 2,43 % compared to > native linux compilering doxygen. > > That's really fast. VMware eat more than 25 % ^^. Huh!? Are you sure about those figures? Some time ago I did some compilation benchmarking with coLinux 0.6.3 I don't have the exact results right now but it was something around compilation under coLinux being about 2.5 times slower than native Linux. Cygwin was about 6 times slower. (I didn't manage to test with VMware yet.) This was on a 1.7 GHz Centrino with 768 MB of RAM, compiling binutils-2.16.1 I would be happy if coLinux 0.6.4 made such a performance improvement but somehow I doubt it ;-) Regards, Bernd |
From: Philippe S. <phi...@si...> - 2006-08-03 07:35:15
|
* Bernd Brandstetter wrote: > * Philippe Stellwag wrote: > > > I've tested it, it is really faster -- not only a little bit > > (-;. coLinux (Windows host) 0.6.4 losing 14,78 % of performance > > compared to native linux compilering (tested with doxygen > > 1.4.7). coLinux (Linux host) 0.6.4 only loses 2,43 % compared to > > native linux compilering doxygen. > > > > That's really fast. VMware eat more than 25 % ^^. >=20 > Huh!? Are you sure about those figures? Yes, I'm sure. I've investigated those figures the past last year (diploma thesis). > Some time ago I did some compilation benchmarking with coLinux 0.6.3 > I don't have the exact results right now but it was something around=20 > compilation under coLinux being about 2.5 times slower than native Linu= x.=20 > Cygwin was about 6 times slower. (I didn't manage to test with VMware=20 > yet.) Yes, compilering on Cygwin is >6 times slower than compilering on coLinux (0.6.3) root filesystem (Ext3).=20 Compared to native Linux compilering, coLinux 0.6.3 is ~16 percent slower -- 0.6.4 needs ~17 percent more time. I've tested it with compilering doxygen/binutils/(and much much more)!=20 But such figures depends on a lot of factors. Bigger sourcecode=20 projects could be faster. Partly, compilering of really big projects=20 on coLinux 0.6.3 rootfs need only <9 percent more time. 250 percent sounds a little too big *???*. I've investigated Cygwin, coLinux, Parallels and VMware. The last virtualization product -- except Cygwin -- is the slowest and needs "only"=20 ~25 percent more time. > I would be happy if coLinux 0.6.4 made such a performance improvement b= ut=20 > somehow I doubt it ;-) No, coLinux 0.6.4 (Windows host) is ~ 1 percent slower than 0.6.3 (see above). However, coLinux (Linux host) is extremly fast. It needs only up to 3 percent longer than compilering under native Linux. So long... Philippe --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-01 09:15:30
|
Philippe Stellwag wrote: > Partly there isn't any chance to write/modify a file within > coLinux on a COFS share :-(. VIM say sometimes that fsync() fails. > If on coLinux done modifications seen on Windows, they are never > completely and valid! (Only tested with 0.6.{3,4}!!!) The question is, how/why does vim call the fsync. A simple close of file is enough. It is a badly idea to force a sync on a 'async' filesystem? My VIM works. # vim --version VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Sep 23 2003 23:25:02) Included patches: 1-8, 10-12, 14-21, 25-32, 34-35, 37, 40-41, 43-46, 48-55, 57-59, 61-89 Editor mcedit works. I use it daily on cofs. I copy and move file from coLinux development over cofs to windows and via versa. No problems. An other people runs a gcc on cofs. -- Henry Nestler |
From: Philippe S. <phi...@si...> - 2006-08-01 09:35:39
|
* Henry Nestler wrote: > * Philippe Stellwag wrote: > > > Partly there isn't any chance to write/modify a file within > > coLinux on a COFS share :-(. VIM say sometimes that fsync() fails. > > If on coLinux done modifications seen on Windows, they are never > > completely and valid! (Only tested with 0.6.{3,4}!!!) >=20 > The question is, how/why does vim call the fsync. A simple close of=20 > file is enough. It is a badly idea to force a sync on a 'async' filesy= stem? That's it, yes! > My VIM works. > # vim --version > VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Sep 23 2003 23:25:02) > Included patches: 1-8, 10-12, 14-21, 25-32, 34-35, 37, 40-41, 43-46,=20 > 48-55, 57-59, 61-89 [CUT] user@linux:~$ vim --version VIM - Vi IMproved 6.3 (2004 June 7, compiled Jul 30 2005 12:31:05) Included patches: 1-71, 81-82 Compiled by no...@de... Big version without GUI. Features included (+) or not (-): +arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cind= ent=20 -clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comm= ents=20 +cryptv +cscope +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eva= l=20 +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -foot= er=20 +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +l= angmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession=20 +modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm=20 +mouse_netterm +mouse_xterm +multi_byte +multi_lang -netbeans_intg -osfil= etype=20 +path_extra -perl +postscript +printer -python +quickfix +rightleft -ruby= =20 +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax=20 +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse=20 +textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visu= al=20 +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writeback= up=20 -X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save=20 system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" fall-back for $VIM: "/usr/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -Wall =20 Linking: gcc -L/usr/local/lib -o vim -lncurses -lgpm -ldl =20 [/CUT] Mine sucks, however ;). I use the standard package of Debian=20 Sarge -- perhaps not the really latest. > Editor mcedit works. I use it daily on cofs. The editor nano works, too. > I copy and move file from coLinux development over cofs to windows and=20 > via versa. No problems. I've done this the past half year -- yes this works really fine. > An other people runs a gcc on cofs. That's not a good idea, I've tested it a few times. Results are not worki= ng=20 executables. Further more the filesystem driver behind COFS (in my case N= TFS) couldn't handle symlinks -- okay NTFS could, I know :). By the way, compile on COFS takes up to ~250 percent longer ^^ compared=20 to coLinux root fs. Grusz, Philippe --=20 Siemens AG A&D MC RD3 Frauenauracher Stra=DFe 80 91056 Erlangen Phone: +49 (9131) 98 - 4240 |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-07-31 14:28:39
|
Philippe Stellwag wrote: > Hi @ll, > > I'm trying to build coLinux (0.6.4) for running it on a Linux > host (Debian Sarge | Kernel: 2.6.17.6-vanilla PREEMPT). For > coLinux I've got an root filesystem (LFS with Init from Busybox and > 2.6.11.12-coLinux-vanilla as kernel), with runs fine on a Windows OS. The last usable kernel version is 2.6.12, that exist in the devel version of coLinux. > The Wiki page[1] didn't help me :-(. > > [1] http://wiki.colinux.org/mediawiki/index.php/CoLinux_on_Linux > > What have I done? Please read the file doc/building in the source. > (1) Installing tofrodos package for getting unix2dos command on > my host maschine and changing the coLinux configure script for > getting unix2dos version (-:. This you not need for coLinux on Linux host. You can comment out from configure script. > (2) Changing my version.h (from my host vanilla kernel) and > correct "HOST_EXTRAVERSION" to "HOST_EXTRAVERSION=.6-vanilla". That's wrong. You should not do this on target kernel. The kernel patch from coLinux source does it. If you does this on your Host kernel source, then it is ok. But you should run exact this kernel than. > > (3) Running the coLinux configure script: > > # ./configure --target=i686-pc-linux --downloaddir=/tmp --targetkerneldir=/tmp/linux-2.6.11 --hostkerneldir=/usr/src/linux > target_cpu=i686 > target_vendor=pc > target_os=linux > Setting colinux_os=linux > Setting prefix=/usr/src/linux > Setting distdir=/usr/src/linux/dist > colinux_version=0.6.4 > target_kernel_dir=v2.6 > target_kernel_version=2.6.11 > Setting targetkerneldir=/tmp/linux-2.6.11 > UNAME_RELEASE=2.6.17.6-vanilla > HOST_VERSION=2 > HOST_PATCHLEVEL=6 > HOST_SUBLEVEL=17 > HOST_EXTRAVERSION=.6-vanilla > Setting logfile=/usr/src/log/build-colinux-$$.log > Checking for wget ... found > Checking for Python interpreter ... found > Checking for patch ... found > Checking for make ... found > Checking for binutils host ... (2.15.0) found > Checking for gcc host ... (3.4.4) found > Checking for gcc g++ ... (3.4.4) found > Checking for FLTK devel (patched) ... (1.1.6) found > Checking for mxml devel ... found > Create toplevel Makefile > Create bin/user-build.cfg > Configure DONE > > Ready for "make download && make && make install" > > (4) Running "make" can't find cooperative.h: > > # make > make[1]: Entering directory `/usr/src/coLinux-0.6.4/src' > [...] > In file included from ./colinux/common/console.h:13, > from colinux/user/console/widget.h:20, > from colinux/user/console/widget.cpp:13: > ./colinux/common/common.h:28:31: linux/cooperative.h: No such file or directory You tryed to use an unpatched coLinux kernel (target kernel). > I think, this problem containing the lack of the target kernel > (--targetkerneldir=/tmp/linux-2.6.11). This (targetkerneldir) directory should be empty or patched right. Let it empty. Than the build system will unpack and patch the kernel for you. Try to run the script bin/build-kernel.sh There you see the steps for building coLinux Target Kernel. -- Henry Nestler |