Menu
▾
▴
open-vm-tools-devel — List for open-vm-tools developer discussions.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(30) |
Oct
(50) |
Nov
(42) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(36) |
Feb
(13) |
Mar
(74) |
Apr
(17) |
May
(62) |
Jun
(53) |
Jul
(32) |
Aug
(58) |
Sep
(44) |
Oct
(21) |
Nov
(35) |
Dec
(53) |
| 2009 |
Jan
(43) |
Feb
(58) |
Mar
(14) |
Apr
(16) |
May
(61) |
Jun
(49) |
Jul
(11) |
Aug
(22) |
Sep
(37) |
Oct
(12) |
Nov
(23) |
Dec
(10) |
| 2010 |
Jan
(21) |
Feb
(13) |
Mar
(5) |
Apr
(18) |
May
(14) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
(13) |
Oct
(8) |
Nov
(11) |
Dec
(14) |
| 2011 |
Jan
(13) |
Feb
(19) |
Mar
(16) |
Apr
(10) |
May
(22) |
Jun
(4) |
Jul
(63) |
Aug
(14) |
Sep
(10) |
Oct
(12) |
Nov
(10) |
Dec
(43) |
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(35) |
Apr
(1) |
May
(32) |
Jun
(8) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
(25) |
Nov
(14) |
Dec
(4) |
| 2013 |
Jan
(12) |
Feb
(6) |
Mar
(15) |
Apr
(24) |
May
(9) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(3) |
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2009-01-23 15:47:34
|
Tracker item #2531283, was opened at 2009-01-23 16:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2531283&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mna-news (mna-news) Assigned to: Nobody/Anonymous (nobody) Summary: modules/linux/vsock does not compile Initial Comment: am using 2.6.28.1 kernel and try to compile open-vm-tools-2009.01.21-142982. (i have apply the patch found here https://sourceforge.net/tracker/download.php?group_id=204462&atid=989708&file_id=310300&aid=2530616 which seem to work properly for me) Using 2.6.x kernel build system. Building VMCI Sockets with VMCI module symbols. make[2]: Entering directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vsock' cp -f /tmp/VMwareVMCIModule.symvers ./Module.symvers make -C /lib/modules/2.6.28.1/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vsock/linux/af_vsock.o /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vsock/linux/af_vsock.c: In function `VMCISock_KernelDeregister': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vsock/linux/af_vsock.c:210: d▒sol▒, pas implant▒: l'enlignage de l'appel ▒ ▒ VSockVmciTestUnregister ▒: function body not available a ▒chou▒ /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vsock/linux/af_vsock.c:627: d▒sol▒, pas implant▒: appel▒ d'ici make[4]: *** [/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vsock/linux/af_vsock.o] Erreur 1 make[3]: *** [_module_/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vsock] Erreur 2 make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make[2]: *** [vsock.ko] Erreur 2 make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vsock' make[1]: *** [vsock] Erreur 2 make[1]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules' make: *** [all-recursive] Erreur 1 thanks for your attention. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2531283&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-23 15:42:56
|
Tracker item #2530616, was opened at 2009-01-23 09:16 Message generated for change (Comment added) made by mna-news You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530616&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mna-news (mna-news) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs/page.c does not compile Initial Comment: am trying to compile "open-vm-tools-2009.01.21-142982" on a kernel version 2.6.28.1 and there are somes troubles ... [...) make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsDoWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: attention : ISO C89 interdit les m▒langes de d▒clarations et de code /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: erreur: d▒claration implicite de la fonction ▒ __grab_cache_page ▒ /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: attention : affectation transforme un entier en pointeur sans transtypage make[4]: *** [/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Erreur 1 make[3]: *** [_module_/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Erreur 2 make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make[2]: *** [vmhgfs.ko] Erreur 2 make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make[1]: *** [vmhgfs] Erreur 2 make[1]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules' make: *** [all-recursive] Erreur 1 if anybody has an idear or solution ... thanks in advance mna. ---------------------------------------------------------------------- >Comment By: mna-news (mna-news) Date: 2009-01-23 16:42 Message: I have try your patch, it's seem to work, i can compile the vmhgfs kernel module. (but i have another trouble in vsocks ... i will open another ticket with the other trouble) [...] Using 2.6.x kernel build system. make[2]: Entering directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make -C /lib/modules/2.6.28.1/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/request.o CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/rpcout.o CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/stubs.o CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/super.o LD [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/vmhgfs.o Building modules, stage 2. MODPOST 1 modules CC /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/vmhgfs.mod.o LD [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/vmhgfs.ko make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make -C $PWD SRCROOT=$PWD/. postbuild make[3]: Entering directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make[3]: ▒ postbuild ▒ est ▒ jour. make[3]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' cp -f vmhgfs.ko ./../vmhgfs.o make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make VM_UNAME=2.6.28.1 -C "../modules/linux/vsock" Using 2.6.x kernel build system. Building VMCI Sockets with VMCI module symbols. many thanks for your help. mna. ---------------------------------------------------------------------- Comment By: Dmitry Torokhov (dtor) Date: 2009-01-23 16:13 Message: Could you please try the patch I just uploaded? Go to Linux HGFS directory and apply with -p3. Thanks! ---------------------------------------------------------------------- Comment By: Hemp Cluster (jointy) Date: 2009-01-23 10:31 Message: Hi, On my gentoobox I ran into the same problems. [code] CC [M] /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function 'HgfsDoWriteBegin': /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: warning: ISO C90 forbids mixed declarations and code /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function 'HgfsWriteBegin': /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: error: implicit declaration of function '__grab_cache_page' /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: warning: assignment makes pointer from integer without a cast make[2]: *** [/var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Error 1 make[1]: *** [_module_/var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.28-gentoo-r1' make: *** [vmhgfs.ko] Error 2 * * ERROR: app-emulation/open-vm-tools-0.0.20090121.142982 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3327: Called linux-mod_src_compile * environment, line 2499: Called die * The specific snippet of code: * eval "emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS} " || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}"; * The die message: * Unable to emake HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= auto-build HEADER_DIR=/usr/src/linux/include BUILD_DIR=/lib/modules/2.6.28-gentoo-r1/build [/code] The build log you will find here. http://pastebin.com/m34c54235 and usefull infos about the System you will find here. http://pastebin.com/m497e3088 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530616&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-23 15:13:02
|
Tracker item #2530616, was opened at 2009-01-23 00:16 Message generated for change (Comment added) made by dtor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530616&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mna-news (mna-news) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs/page.c does not compile Initial Comment: am trying to compile "open-vm-tools-2009.01.21-142982" on a kernel version 2.6.28.1 and there are somes troubles ... [...) make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsDoWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: attention : ISO C89 interdit les m▒langes de d▒clarations et de code /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: erreur: d▒claration implicite de la fonction ▒ __grab_cache_page ▒ /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: attention : affectation transforme un entier en pointeur sans transtypage make[4]: *** [/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Erreur 1 make[3]: *** [_module_/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Erreur 2 make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make[2]: *** [vmhgfs.ko] Erreur 2 make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make[1]: *** [vmhgfs] Erreur 2 make[1]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules' make: *** [all-recursive] Erreur 1 if anybody has an idear or solution ... thanks in advance mna. ---------------------------------------------------------------------- >Comment By: Dmitry Torokhov (dtor) Date: 2009-01-23 07:13 Message: Could you please try the patch I just uploaded? Go to Linux HGFS directory and apply with -p3. Thanks! ---------------------------------------------------------------------- Comment By: Hemp Cluster (jointy) Date: 2009-01-23 01:31 Message: Hi, On my gentoobox I ran into the same problems. [code] CC [M] /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function 'HgfsDoWriteBegin': /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: warning: ISO C90 forbids mixed declarations and code /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function 'HgfsWriteBegin': /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: error: implicit declaration of function '__grab_cache_page' /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: warning: assignment makes pointer from integer without a cast make[2]: *** [/var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Error 1 make[1]: *** [_module_/var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.28-gentoo-r1' make: *** [vmhgfs.ko] Error 2 * * ERROR: app-emulation/open-vm-tools-0.0.20090121.142982 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3327: Called linux-mod_src_compile * environment, line 2499: Called die * The specific snippet of code: * eval "emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS} " || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}"; * The die message: * Unable to emake HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= auto-build HEADER_DIR=/usr/src/linux/include BUILD_DIR=/lib/modules/2.6.28-gentoo-r1/build [/code] The build log you will find here. http://pastebin.com/m34c54235 and usefull infos about the System you will find here. http://pastebin.com/m497e3088 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530616&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-23 09:32:07
|
Tracker item #2530616, was opened at 2009-01-23 09:16 Message generated for change (Comment added) made by jointy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530616&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mna-news (mna-news) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs/page.c does not compile Initial Comment: am trying to compile "open-vm-tools-2009.01.21-142982" on a kernel version 2.6.28.1 and there are somes troubles ... [...) make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsDoWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: attention : ISO C89 interdit les m▒langes de d▒clarations et de code /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: erreur: d▒claration implicite de la fonction ▒ __grab_cache_page ▒ /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: attention : affectation transforme un entier en pointeur sans transtypage make[4]: *** [/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Erreur 1 make[3]: *** [_module_/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Erreur 2 make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make[2]: *** [vmhgfs.ko] Erreur 2 make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make[1]: *** [vmhgfs] Erreur 2 make[1]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules' make: *** [all-recursive] Erreur 1 if anybody has an idear or solution ... thanks in advance mna. ---------------------------------------------------------------------- Comment By: Hemp Cluster (jointy) Date: 2009-01-23 10:31 Message: Hi, On my gentoobox I ran into the same problems. [code] CC [M] /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function 'HgfsDoWriteBegin': /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: warning: ISO C90 forbids mixed declarations and code /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function 'HgfsWriteBegin': /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: error: implicit declaration of function '__grab_cache_page' /var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: warning: assignment makes pointer from integer without a cast make[2]: *** [/var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Error 1 make[1]: *** [_module_/var/tmp/portage/app-emulation/open-vm-tools-0.0.20090121.142982/work/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.28-gentoo-r1' make: *** [vmhgfs.ko] Error 2 * * ERROR: app-emulation/open-vm-tools-0.0.20090121.142982 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3327: Called linux-mod_src_compile * environment, line 2499: Called die * The specific snippet of code: * eval "emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS} " || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}"; * The die message: * Unable to emake HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= auto-build HEADER_DIR=/usr/src/linux/include BUILD_DIR=/lib/modules/2.6.28-gentoo-r1/build [/code] The build log you will find here. http://pastebin.com/m34c54235 and usefull infos about the System you will find here. http://pastebin.com/m497e3088 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530616&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-23 08:43:54
|
Tracker item #2530652, was opened at 2009-01-23 09:42 Message generated for change (Comment added) made by mna-news You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530652&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: mna-news (mna-news) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs/page.c does not compile Initial Comment: am trying to compile "open-vm-tools-2009.01.21-142982" on a kernel version 2.6.28.1 and there are somes troubles ... [...) make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsDoWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: attention : ISO C89 interdit les m▒langes de d▒clarations et de code /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: erreur: d▒claration implicite de la fonction ▒ __grab_cache_page ▒ /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: attention : affectation transforme un entier en pointeur sans transtypage make[4]: *** [/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Erreur 1 make[3]: *** [_module_/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Erreur 2 make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make[2]: *** [vmhgfs.ko] Erreur 2 make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make[1]: *** [vmhgfs] Erreur 2 make[1]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules' make: *** [all-recursive] Erreur 1 if anybody has an idear or solution ... thanks in advance mna. ---------------------------------------------------------------------- >Comment By: mna-news (mna-news) Date: 2009-01-23 09:43 Message: Close because of Duplicate entry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530652&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-23 08:42:16
|
Tracker item #2530652, was opened at 2009-01-23 09:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530652&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mna-news (mna-news) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs/page.c does not compile Initial Comment: am trying to compile "open-vm-tools-2009.01.21-142982" on a kernel version 2.6.28.1 and there are somes troubles ... [...) make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsDoWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: attention : ISO C89 interdit les m▒langes de d▒clarations et de code /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: erreur: d▒claration implicite de la fonction ▒ __grab_cache_page ▒ /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: attention : affectation transforme un entier en pointeur sans transtypage make[4]: *** [/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Erreur 1 make[3]: *** [_module_/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Erreur 2 make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make[2]: *** [vmhgfs.ko] Erreur 2 make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make[1]: *** [vmhgfs] Erreur 2 make[1]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules' make: *** [all-recursive] Erreur 1 if anybody has an idear or solution ... thanks in advance mna. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530652&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-23 08:16:41
|
Tracker item #2530616, was opened at 2009-01-23 09:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530616&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mna-news (mna-news) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs/page.c does not compile Initial Comment: am trying to compile "open-vm-tools-2009.01.21-142982" on a kernel version 2.6.28.1 and there are somes troubles ... [...) make[3]: Entering directory `/usr/src/linux-2.6.28.1' CC [M] /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsDoWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:763: attention : ISO C89 interdit les m▒langes de d▒clarations et de code /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c: In function `HgfsWriteBegin': /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: erreur: d▒claration implicite de la fonction ▒ __grab_cache_page ▒ /tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.c:867: attention : affectation transforme un entier en pointeur sans transtypage make[4]: *** [/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs/page.o] Erreur 1 make[3]: *** [_module_/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs] Erreur 2 make[3]: Leaving directory `/usr/src/linux-2.6.28.1' make[2]: *** [vmhgfs.ko] Erreur 2 make[2]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules/linux/vmhgfs' make[1]: *** [vmhgfs] Erreur 2 make[1]: Leaving directory `/tmp/open-vm-tools-2009.01.21-142982/modules' make: *** [all-recursive] Erreur 1 if anybody has an idear or solution ... thanks in advance mna. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2530616&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-22 14:14:13
|
Tracker item #1865635, was opened at 2008-01-07 05:00 Message generated for change (Comment added) made by dimstar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1865635&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Russell Harmon (eatnumber1) Assigned to: Nobody/Anonymous (nobody) Summary: FEATURE: Add the ability to include in the kernel. Initial Comment: It would be VERY nice if a makefile and instructions were included for including open-vm-tools as part of the kernel. I help maintain a small kernel patchset and would like to include open-vm-tools in it. I will write an example Makefile if I get the time. ---------------------------------------------------------------------- Comment By: Dominique Leuenberger (dimstar) Date: 2009-01-22 15:14 Message: One of the kernel devs (Greg KH) actually offered to support for inclusion in the kernel with fixing up things that are required. He mentioned that an estimated amount of work would be one day (estimated). The ;issue' at hand is less the fact that it CAN be done, but the fact the upstream is not ready for this switch yet. (also read up on https://sourceforge.net/mailarchive/forum.php?thread_name=496CCCD2020000290000D724%40mail2.tmf-group.com&forum_name=open-vm-tools-devel ) ---------------------------------------------------------------------- Comment By: Russell Harmon (eatnumber1) Date: 2009-01-22 15:07 Message: A Makefile for the linux kernel has to follow a specific format. It looks like open-vm-tools/modules/linux/vmhgfs/Makefile.kernel would work, but I haven't really tried it. You also need a Kconfig. They're not very complex, you can find an example one almost anywhere in the kernel. P.S. I'm no longer actively doing kernel development because of time concerns, and so I probably won't be able to make an example Makefile. ---------------------------------------------------------------------- Comment By: Russell Harmon (eatnumber1) Date: 2008-10-07 01:57 Message: It needs the Makefile to follow the conventions outlined at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/makefiles.txt;h=7a7753321a263f62c2a00c9d0e348716e701ac2c;hb=HEAD (or Documentation/kbuild/makefiles.txt in the tree), and you need to create a kbuild file defining what shows up in menuconfig (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/kconfig-language.txt;h=c412c245848f9116fb05361bb78e5189b43cfd51;hb=HEAD or Documentation/kbuild/kconfig-language.txt in the tree). ---------------------------------------------------------------------- Comment By: Dmitriy (bryndin) Date: 2008-05-09 20:56 Message: Logged In: YES user_id=1494464 Originator: NO I'm using it as dkms modules. ---------------------------------------------------------------------- Comment By: ECL (sopwith) Date: 2008-02-08 22:54 Message: Logged In: YES user_id=18318 Originator: NO Hey Russell - any progress with that example Makefile? I know the kernel modules already include a Makefile that ties in with the 2.6 kernel build system. While I'm totally ignorant about the kernel build system, what happens if you just 'mv open-vm-tools-2008.01.23*/modules/linux/vmhgfs /usr/src/linux/fs/vmhgfs' and fix up the top-level Makefiles to match? Are there any other technical tasks involved in integrating the modules into a kernel tree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1865635&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-22 14:07:31
|
Tracker item #1865635, was opened at 2008-01-06 23:00 Message generated for change (Comment added) made by eatnumber1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1865635&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Russell Harmon (eatnumber1) Assigned to: Nobody/Anonymous (nobody) Summary: FEATURE: Add the ability to include in the kernel. Initial Comment: It would be VERY nice if a makefile and instructions were included for including open-vm-tools as part of the kernel. I help maintain a small kernel patchset and would like to include open-vm-tools in it. I will write an example Makefile if I get the time. ---------------------------------------------------------------------- >Comment By: Russell Harmon (eatnumber1) Date: 2009-01-22 09:07 Message: A Makefile for the linux kernel has to follow a specific format. It looks like open-vm-tools/modules/linux/vmhgfs/Makefile.kernel would work, but I haven't really tried it. You also need a Kconfig. They're not very complex, you can find an example one almost anywhere in the kernel. P.S. I'm no longer actively doing kernel development because of time concerns, and so I probably won't be able to make an example Makefile. ---------------------------------------------------------------------- Comment By: Russell Harmon (eatnumber1) Date: 2008-10-06 19:57 Message: It needs the Makefile to follow the conventions outlined at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/makefiles.txt;h=7a7753321a263f62c2a00c9d0e348716e701ac2c;hb=HEAD (or Documentation/kbuild/makefiles.txt in the tree), and you need to create a kbuild file defining what shows up in menuconfig (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/kconfig-language.txt;h=c412c245848f9116fb05361bb78e5189b43cfd51;hb=HEAD or Documentation/kbuild/kconfig-language.txt in the tree). ---------------------------------------------------------------------- Comment By: Dmitriy (bryndin) Date: 2008-05-09 14:56 Message: Logged In: YES user_id=1494464 Originator: NO I'm using it as dkms modules. ---------------------------------------------------------------------- Comment By: ECL (sopwith) Date: 2008-02-08 16:54 Message: Logged In: YES user_id=18318 Originator: NO Hey Russell - any progress with that example Makefile? I know the kernel modules already include a Makefile that ties in with the 2.6 kernel build system. While I'm totally ignorant about the kernel build system, what happens if you just 'mv open-vm-tools-2008.01.23*/modules/linux/vmhgfs /usr/src/linux/fs/vmhgfs' and fix up the top-level Makefiles to match? Are there any other technical tasks involved in integrating the modules into a kernel tree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1865635&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-21 23:06:18
|
Tracker item #1865635, was opened at 2008-01-06 20:00 Message generated for change (Settings changed) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1865635&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Russell Harmon (eatnumber1) >Assigned to: Nobody/Anonymous (nobody) Summary: FEATURE: Add the ability to include in the kernel. Initial Comment: It would be VERY nice if a makefile and instructions were included for including open-vm-tools as part of the kernel. I help maintain a small kernel patchset and would like to include open-vm-tools in it. I will write an example Makefile if I get the time. ---------------------------------------------------------------------- Comment By: Russell Harmon (eatnumber1) Date: 2008-10-06 16:57 Message: It needs the Makefile to follow the conventions outlined at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/makefiles.txt;h=7a7753321a263f62c2a00c9d0e348716e701ac2c;hb=HEAD (or Documentation/kbuild/makefiles.txt in the tree), and you need to create a kbuild file defining what shows up in menuconfig (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kbuild/kconfig-language.txt;h=c412c245848f9116fb05361bb78e5189b43cfd51;hb=HEAD or Documentation/kbuild/kconfig-language.txt in the tree). ---------------------------------------------------------------------- Comment By: Dmitriy (bryndin) Date: 2008-05-09 11:56 Message: Logged In: YES user_id=1494464 Originator: NO I'm using it as dkms modules. ---------------------------------------------------------------------- Comment By: ECL (sopwith) Date: 2008-02-08 13:54 Message: Logged In: YES user_id=18318 Originator: NO Hey Russell - any progress with that example Makefile? I know the kernel modules already include a Makefile that ties in with the 2.6 kernel build system. While I'm totally ignorant about the kernel build system, what happens if you just 'mv open-vm-tools-2008.01.23*/modules/linux/vmhgfs /usr/src/linux/fs/vmhgfs' and fix up the top-level Makefiles to match? Are there any other technical tasks involved in integrating the modules into a kernel tree? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1865635&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-21 22:57:22
|
Tracker item #2301228, was opened at 2008-11-16 14:15 Message generated for change (Comment added) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2301228&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: John Brooks (aspecial) Assigned to: Nobody/Anonymous (nobody) Summary: Build fails with --disable-multimon in unity Initial Comment: The build of version 2008.10.10 with --disable-multimon (no xinerama support) and with Unity enabled fails in lib/unity/unityPlatformX11.c due to extensive use of the header, functions, and structures from xinerama not contained within #ifndef NO_MULTIMON - making a build with unity and without xinerama impossible. Due to use of structures from xinerama, it's too much for me to resolve myself. If this isn't something that is intended to be fixed (i.e. a dependency will be made on xinerama), let me know and i'll get the gentoo ebuild updated accordingly - currently it tries to use --disable-multimon whenever xinerama isn't available/enabled. ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2009-01-21 14:57 Message: This was actually fixed in the 2008.12.24 release. ---------------------------------------------------------------------- Comment By: John Brooks (aspecial) Date: 2008-11-19 03:24 Message: Sounds good. I've filed a gentoo bug to this effect, to have a dependency added for xinerama when unity is enabled. Thanks. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2008-11-17 19:56 Message: Hi John, To the best of my knowledge, Unity depends on the multimon functionality, so I guess you'll need to update the ebuild. I'll keep this bug open to add a similar check in the configure script itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2301228&group_id=204462 |
|
From: Dmitry T. <dt...@vm...> - 2009-01-21 21:15:33
|
Hi Dominique, On Tuesday 20 January 2009 23:58:35 Dominique Leuenberger wrote: > >>> On 1/20/2009 at 11:45 PM, Dmitry Torokhov <dt...@vm...> wrote: > > > > - DND code needs to try accessing new vmblock-fuse location before > > falling back to the legacy vmblock location. > > > > - Our startup scripts need to verify presence of FUSE module and > > compatible version of libfuse and load and mount vmblock-fuse instead of > > vmblock if FUSE > > I'm all in favor of a solution that works out in long-term. And fuse seems > to become stronger and more stable with every release. So supporting it > (and in case of lack of 'something' contributing it straight to fuse > instead of hacking around) would probably be the very best way to go > forward. > > The question would be: how long do you want to maintain both tracks? Why > having the 'fall back' mechanism in? I think we could also just argue that > from open-vm-tools-<random version> on, fuse is required dependency. Or at > least have the code nicely factorized for DnD that it's easy removable > (remove complexity whenever possible). > We need to maintain the fall back mechanism for some time so users who might not be comfortable with using fuse or users who experience problems with it could have a way out until the issue is resolved. -- Dmitry |
|
From: Dominique L. <Dom...@TM...> - 2009-01-21 08:01:21
|
Hi Dmitry >>> On 1/20/2009 at 11:45 PM, Dmitry Torokhov <dt...@vm...> wrote: > While the guest kernel modules are open-sourced they are still not integrated > sad but true ;) > with the mainline kernel and thus suffer from rapid kernel API changes that > happen in mainline. Although getting some of the code upstream should be > possible this can't be said about vmblock driver which exists mainly to work > around the deficiency in gtk DnD protocol. It is highly unlikely that such > driver will be accepted in mainline. > Indeed, if it's just to 'hack up something else' chances for that part are really low I guess. > In the effort to shield ourselves from future API changes we would like to > consider switching from vmblock kernel module to vmblock-fuse as our default > blocking mechanism for DnD. FUSE is pretty stable by now and in addition to > Linux there are also implementations for Solaris and FreeBSD; there were > some > issues with deadlocks with earlier versions of libfuse but I believe they > have > been resolved. > > What we need to change: > > - /proc/fs/vmblock/ can not be used with user space implementation, we need > to > move the mount point somewhere. I'd probably go with /var/run/vmblock or > /var/run/vmblock-fuse. > > - DND code needs to try accessing new vmblock-fuse location before falling > back to the legacy vmblock location. > > - Our startup scripts need to verify presence of FUSE module and compatible > version of libfuse and load and mount vmblock-fuse instead of vmblock if FUSE I'm all in favor of a solution that works out in long-term. And fuse seems to become stronger and more stable with every release. So supporting it (and in case of lack of 'something' contributing it straight to fuse instead of hacking around) would probably be the very best way to go forward. The question would be: how long do you want to maintain both tracks? Why having the 'fall back' mechanism in? I think we could also just argue that from open-vm-tools-<random version> on, fuse is required dependency. Or at least have the code nicely factorized for DnD that it's easy removable (remove complexity whenever possible). Dominique |
|
From: Dmitry T. <dt...@vm...> - 2009-01-20 22:46:50
|
Hi everyone, While the guest kernel modules are open-sourced they are still not integrated with the mainline kernel and thus suffer from rapid kernel API changes that happen in mainline. Although getting some of the code upstream should be possible this can't be said about vmblock driver which exists mainly to work around the deficiency in gtk DnD protocol. It is highly unlikely that such driver will be accepted in mainline. In the effort to shield ourselves from future API changes we would like to consider switching from vmblock kernel module to vmblock-fuse as our default blocking mechanism for DnD. FUSE is pretty stable by now and in addition to Linux there are also implementations for Solaris and FreeBSD; there were some issues with deadlocks with earlier versions of libfuse but I believe they have been resolved. What we need to change: - /proc/fs/vmblock/ can not be used with user space implementation, we need to move the mount point somewhere. I'd probably go with /var/run/vmblock or /var/run/vmblock-fuse. - DND code needs to try accessing new vmblock-fuse location before falling back to the legacy vmblock location. - Our startup scripts need to verify presence of FUSE module and compatible version of libfuse and load and mount vmblock-fuse instead of vmblock if FUSE is available. What do you think? -- Dmitry |
|
From: SourceForge.net <no...@so...> - 2009-01-20 17:20:53
|
Tracker item #2523263, was opened at 2009-01-20 02:31 Message generated for change (Comment added) made by dtor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2523263&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dominique Leuenberger (dimstar) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs stops hibernation Initial Comment: Bug has been copied from openSUSE bug tracker: https://bugzilla.novell.com/show_bug.cgi?id=461340 if vmhgfs kernel module is loaded, the system cannot be suspended anymore. (s2disk /dev/sda1 fails, leaving the call trace below). ---------------------------------------------------------------------- Comment By: Dmitry Torokhov (dtor) Date: 2009-01-20 09:20 Message: I suppose it happens with newer kernels only, right? How about this patch.... if only I could figure out how to attach a new file to this thing... Well, will have to just post it inline. --- bora-vmsoft.orig/hgfs/linux/bdhandler.c +++ bora-vmsoft/hgfs/linux/bdhandler.c @@ -256,7 +256,12 @@ int HgfsBdHandler(void *data) // Ignored { LOG(6, (KERN_DEBUG "VMware hgfs: HgfsBdHandler: Thread starting\n")); + +#ifdef PF_FREEZER_NOSIG + set_freezable_with_signal(); +#else compat_set_freezable(); +#endif for (;;) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2523263&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2009-01-20 10:31:23
|
Tracker item #2523263, was opened at 2009-01-20 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2523263&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dominique Leuenberger (dimstar) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs stops hibernation Initial Comment: Bug has been copied from openSUSE bug tracker: https://bugzilla.novell.com/show_bug.cgi?id=461340 if vmhgfs kernel module is loaded, the system cannot be suspended anymore. (s2disk /dev/sda1 fails, leaving the call trace below). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2523263&group_id=204462 |
|
From: Adar D. <ad...@vm...> - 2009-01-19 10:07:13
|
> The first question is: > what aspect of Virtualization does it test? Something about signals? VmCheck_GetVersion makes the BDOOR_CMD_GETVERSION backdoor call, which, if called within a VMware guest, will cause the vmm to place a "magic" number in register EAX and return control to the guest. > The second question is: > why can't we limit ourselves to only checking the Vmware version by > VmCheck_GetVersion and exit if it returns false? The signal handling code is there because if we're not on a VMware platform, performing the backdoor call will likely trigger a SIGSEGV. We want to handle such cases gracefully so we set up a custom SIGSEGV handler that will jump to just after the call to sigsetjmp if a SIGSEGV is indeed triggered. That lets us correctly report that we're not running under a VMware platform instead of crashing the program using this code. |
|
From: s g <hq9...@ma...> - 2009-01-19 09:54:03
|
Hi guys,
In procedure
Bool VmCheck_IsVirtualWorld(void)
We have this logic for check virtuality in POSIX OSes (extract comes below).
The first question is:
what aspect of Virtualization does it test? Something about signals?
The second question is:
why can't we limit ourselves to only checking the Vmware version by VmCheck_GetVersion and exit if it returns false?
Many thanks!
==========
int signals[] = {
SIGSEGV,
};
struct sigaction olds[ARRAYSIZE(signals)];
if (Signal_SetGroupHandler(signals, olds, ARRAYSIZE(signals),
VmCheckSegvHandler) == 0) {
exit(1);
}
if (sigsetjmp(jmpBuf, TRUE) == 0) {
jmpIsSet = TRUE;
VmCheck_GetVersion(&version, &dummy);
} else {
jmpIsSet = FALSE;
return FALSE;
}
if (Signal_ResetGroupHandler(signals, olds, ARRAYSIZE(signals)) == 0) {
exit(1);
}
==========
|
|
From: Ragavan S <rag...@gm...> - 2009-01-17 03:32:26
|
Hi Sean, On Tue, Jan 13, 2009 at 12:08 PM, Sean Dilda <se...@du...> wrote: > Thanks for putting these out. I think they'll be a great help. > > Where's the best place to report bugs on them? Good question. For now, you can use the bug tracker for the open-vm-tools project. I have created a new category called OSP - please use that. This may not be the right longer term solution, but let's use this for now. > For instance, I just started looking at the packages for RHEL5 and noticed > an issue. /usr/lib/vmware-tools/functions makes use of 'lsb_release' yet > none of the packages actually require redhat-lsb which provides lsb_release. Thanks for catching this. If you don't mind, please create a bug for this and I'll be sure to route it to the right folks. Regards, Ragavan |
|
From: Bentz M. <par...@sk...> - 2009-01-15 11:07:53
|
How to Givve Her Absolute Pleasure? http://cid-7cff328073e5f546.spaces.live.com/blog/cns!7CFF328073E5F546!106.entry/ Drums and conchs and flutes, with the honeyed here on serious business. I am bringing six millions 'with excessive zeal.' nilakantha explains it hinted above, may suffice to afford some cursory of conversation you can choose for my amusement. |
|
From: Ragavan S <rag...@gm...> - 2009-01-14 06:22:39
|
Hi Dominique, > Most of you probably know that I'm packaging open-vm-tools for openSUSE. The packages seem to get quiet some echo and are appreciated. We are definitely among the people that appreciate the work you have done (and continue to do) in packaging up open-vm-tools for openSUSE. Thank you. > That much that plenty of requests appear to have something similiar on the 'host' (open-vm-tools are for the guest only). > > For openSUSE, we provide so called KMPs (Kernel Module Packages) for additional drivers, which are always in sync with the latest updated kernel > version we publish. > Users basically look for a way to have their vmware installed on a system and no need of taking care of the kernel modules when they update the > kernel (6.5 has sort of a mechanism that would ask for the root password and recompile the kernel... but I have rarely seen it working.. normally it > segfaults somewhere). > > What stops us from including the vmware modules into the kernel? Good question. This question has come up on and off often enough that Adar thinks we need an FAQ. Perhaps. But for now, let me at least try and answer this here. As you have mentioned, there are both guest and host kernel modules. Our goal is to eventually get them all upstream. The guest modules will probably happen before the host modules simply because we have an active team working on the former. Now, coming to the reasons that have caused a delay in getting the guest kernel modules upstream. They are mostly (perhaps all?) internal to VMware. Here are a few (which have come up in various email discussions or FAQ posts in the past): 1. Each VMware product today ships with its own version of VMware Tools (and hence the guest kernel modules). While the differences may not be huge between each of these flavors, they are different nevertheless. As a result, there isn't one version of the kernel modules we can clean up and submit upstream. This is a pretty big priority for us and is a pre-requisite for moving towards upstreaming. 2. Slightly related to the above is the current development process for these kernel modules. VMware developers who work on these kernel modules do so in the context of VMware products, release timelines, deadlines etc. To move from this model to doing development upstream is a non-trivial change. Not a technical problem as much as a social one inside the company. 3. Also related to #2 is our current model of supporting new features in VMware products that also include changes to one or more of the guest kernel modules. Since we currently distribute both the product and the guest kernel modules at the same time, we have a lot more control and flexibility in enabling features for our customers. While others (including Greg KH) have pointed out that most other IHVs do *not* do this, the fact is this is our current mode of operation. And whether or not we should change this is still a matter of internal debate. There are a few more, but I think I have already gone into a lot more detail than most people are probably interested in. Having said all this, I should also add that we are currently working on #1 above as it really is the first step we need to take internally. We are also socializing #2 inside the company, so I am cautiously optimistic that we will make progress on this upstreaming topic in the coming weeks/months. > I am even able to pass along an offer from a kernel dev (Greg KH) to format the > drivers for inclusion and offering his help in getting the modules in. I think Greg is known to most of the Kernel hackers and does not need any > further introductions. Otherwise, for sure you know the Linux Driver Project. Adar and I met with Greg at a conference last year where he extended this offer. He has repeated this on several occasions since then. I fully hope to be able to take him up on his offer as well as maybe even use the services of the Linux Driver project. But, as I've explained above we have a few internal steps to take care of first before we can take this one on. > Everything we can do to make the life of users easier on any platform should be a good thing to do. Agreed. open-vm-tools was/is a step in that direction. Upstreaming is another and we expect to get there. Regards, Ragavan |
|
From: Sean D. <se...@du...> - 2009-01-13 20:08:45
|
Ragavan S wrote: > [cross-posting to both the announce and devel lists] > > Hi folks, > > A couple of days ago VMware announced the general availability of > VMware Tools Operating System Specific Packages (OSPs) for several > Linux distributions. Using OSPs, enterprise customers virtualizing > Linux on VI will be able to install/update/manage their VMware Tools > installations using the guest operating systems' native packaging > format (rpm, deb etc) and update mechanisms (apt, yum, rug, etc). > > More details including a list of supported ESX releases, guest > operating systems, documentation and package repository are available > from the OSP web page at http://packages.vmware.com. > > Naturally, this is bound to raise several questions related to OSPs > and open-vm-tools. To help answer some of the common ones, we've put > together this short Q&A page on the open-vm-tools project wiki page at > http://open-vm-tools.wiki.sourceforge.net/OSP. > > Please take a look and let us know if you have any additional > questions/comments on this topic. > Thanks for putting these out. I think they'll be a great help. Where's the best place to report bugs on them? For instance, I just started looking at the packages for RHEL5 and noticed an issue. /usr/lib/vmware-tools/functions makes use of 'lsb_release' yet none of the packages actually require redhat-lsb which provides lsb_release. |
|
From: Dominique L. <Dom...@TM...> - 2009-01-13 16:39:39
|
Hi everybody, Most of you probably know that I'm packaging open-vm-tools for openSUSE. The packages seem to get quiet some echo and are appreciated. That much that plenty of requests appear to have something similiar on the 'host' (open-vm-tools are for the guest only). For openSUSE, we provide so called KMPs (Kernel Module Packages) for additional drivers, which are always in sync with the latest updated kernel version we publish. Users basically look for a way to have their vmware installed on a system and no need of taking care of the kernel modules when they update the kernel (6.5 has sort of a mechanism that would ask for the root password and recompile the kernel... but I have rarely seen it working.. normally it segfaults somewhere). What stops us from including the vmware modules into the kernel? I am even able to pass along an offer from a kernel dev (Greg KH) to format the drivers for inclusion and offering his help in getting the modules in. I think Greg is known to most of the Kernel hackers and does not need any further introductions. Otherwise, for sure you know the Linux Driver Project. Everything we can do to make the life of users easier on any platform should be a good thing to do. Best regards, Dominique |
|
From: Marcelo V. <mv...@vm...> - 2009-01-12 20:41:04
|
Hi Sergey, Sergey Grechin wrote: > The question is - where are backdoor interface specs published? Are > they open? I mean how VMWare let us know > how we have to communicate with virtualware? There are no published specs - since implementing the backend of a backdoor call requires modifications to non-open-source VMware code (i.e., the binaries that run on the host OS), I don't think VMware has thought about opening that up as a public API. The addition of the VMCI device and VMCI sockets module (vsock) is one way we're trying to change this, but currently VMware Tools themselves still use the backdoor. > Okay, now for some reason > this magic asm stuff with those magic constants work, but who can > guarantee that it will remain to be compatible with newer VMWare > versions? Changing these things would break backwards compatibility with existing VMware product releases (since the same values are used in the binaries running on the host OS), and cause us tremendous headaches. :-) So it's very, very improbable that they will change. -- - Marcelo |
|
From: Westfloor <of...@we...> - 2009-01-12 19:12:23
|
WESTFLOOR - PARDOSELI TEHNICE STIRBEI VODA 53-55, BUCURESTI; TEL: 021.318.21.25; FAX: 021.311.14.56; MOBIL: 0740.001.101 Atasat - oferta pret pardoseala tehnica flotanta (suprainaltata) valabila ian/feb 2009. |
58 messages has been excluded from this view by a project administrator.
