[RFC] QEMU KVM target

[RFC] QEMU KVM target

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

Howdy,

Here's a tiny patch that adds a i386-kvm target.  The main difference 
between the i386-kvm and i386-softmmu target is that the -kvm target 
does not have any of the dyngen infrastructure.  This means that it will 
build with gcc-4.  I know you can do --cc=gcc to use gcc-4 but quite a 
few versions of gcc-4 have trouble with compiling dyngen.

I also suspect this may prove useful down the road.  What do other 
people think?  I'm not terribly tied to the i386-kvm name for what it's 
worth.

Regards,

Anthony Liguori

[-- Attachment #2: kvm-no-gcc4.diff --]
[-- Type: text/x-patch, Size: 5894 bytes --]

diff -r 64fb395dc8f1 configure
--- a/configure	Thu Feb 15 14:36:40 2007 +0000
+++ b/configure	Mon Feb 19 18:22:08 2007 -0600
@@ -3,8 +3,6 @@ prefix=/usr/kvm
 prefix=/usr/kvm
 kerneldir=/lib/modules/$(uname -r)/build
 want_module=1
-qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
-disable_gcc_check=
 
 usage() {
     cat <<-EOF
@@ -15,20 +13,11 @@ usage() {
 	    --prefix=PREFIX        where to install things ($prefix)
 	    --with-patched-kernel  don't use external module
 	    --kerneldir=DIR        kernel build directory ($kerneldir)
-	    --qemu-cc="$qemu_cc"   compiler for qemu (needs gcc3.x) ($qemu_cc)
-	    --disable-gcc-check    don't insist on gcc-3.x
                                    - this will break running without kvm
 EOF
     exit 1
 }
 
-
-# prefer gcc if its version is 3.* ( over a compat-gcc )
-# do it before parsing command line arguments to enable the user
-#    to specify a specific gcc he/she likes.
-if gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]'; then
-	qemu_cc=gcc
-fi
 
 while [[ "$1" = -* ]]; do
     opt="$1"; shift
@@ -47,12 +36,6 @@ while [[ "$1" = -* ]]; do
 	--with-patched-kernel)
 	    want_module=
 	    ;;
-	--qemu-cc)
-	    qemu_cc="$arg"
-	    ;;
-	--disable-gcc-check)
-	    disable_gcc_check=1
-	    ;;
 	--help)
 	    usage
 	    ;;
@@ -61,11 +44,6 @@ while [[ "$1" = -* ]]; do
 	    ;;
     esac
 done
-
-if [[ -z "$qemu_cc" ]]; then
-    echo "$0: cannot locate gcc 3.x. please install it or specify with --qemu-cc"
-    exit 1
-fi
 
 libkvm_kerneldir="$kerneldir"
 if (( want_module )); then
@@ -81,12 +59,12 @@ target_cpu() {
 }
 
 (cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
-(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
+(cd qemu; ./configure --target-list=i386-kvm \
     --disable-kqemu --extra-cflags="-I $PWD/../user" \
     --extra-ldflags="-L $PWD/../user" \
     --enable-kvm --kernel-path="$libkvm_kerneldir" \
     --enable-alsa \
-    ${disable_gcc_check:+"--disable-gcc-check"} \
+    --disable-gcc-check \
     --prefix="$prefix"
 )
 
diff -r 64fb395dc8f1 qemu/Makefile.target
--- a/qemu/Makefile.target	Thu Feb 15 14:36:40 2007 +0000
+++ b/qemu/Makefile.target	Mon Feb 19 18:15:02 2007 -0600
@@ -52,7 +52,11 @@ QEMU_USER=qemu-$(TARGET_ARCH2)
 # system emulator name
 ifdef CONFIG_SOFTMMU
 ifeq ($(TARGET_ARCH), i386)
+ifdef CONFIG_KVM
+QEMU_SYSTEM=qemu-kvm$(EXESUF)
+else
 QEMU_SYSTEM=qemu$(EXESUF)
+endif
 else
 QEMU_SYSTEM=qemu-system-$(TARGET_ARCH2)$(EXESUF)
 endif
@@ -231,8 +235,10 @@ OBJS+= libqemu.a
 OBJS+= libqemu.a
 
 # cpu emulator library
-LIBOBJS=exec.o kqemu.o qemu-kvm.o translate-op.o translate-all.o cpu-exec.o\
-        translate.o op.o
+LIBOBJS=exec.o kqemu.o qemu-kvm.o cpu-exec.o
+ifndef CONFIG_KVM
+LIBOBJS+=translate.o op.o translate-op.o translate-all.o 
+endif
 ifdef CONFIG_SOFTFLOAT
 LIBOBJS+=fpu/softfloat.o
 else
diff -r 64fb395dc8f1 qemu/configure
--- a/qemu/configure	Thu Feb 15 14:36:40 2007 +0000
+++ b/qemu/configure	Mon Feb 19 18:14:17 2007 -0600
@@ -819,6 +819,11 @@ target_user_only="no"
 target_user_only="no"
 if expr $target : '.*-user' > /dev/null ; then
   target_user_only="yes"
+fi
+target_kvm="no"
+if expr $target : '.*-kvm' > /dev/null ; then
+  target_kvm="yes"
+  target_softmmu="yes"
 fi
 
 target_linux_user="no"
@@ -943,6 +948,10 @@ if test "$target_softmmu" = "yes" ; then
   echo "CONFIG_SOFTMMU=yes" >> $config_mak
   echo "#define CONFIG_SOFTMMU 1" >> $config_h
 fi
+if test "$target_kvm" = "yes" ; then
+  echo "CONFIG_KVM=yes" >> $config_mak
+  echo "#define CONFIG_KVM 1" >> $config_h
+fi
 if test "$target_user_only" = "yes" ; then
   echo "CONFIG_USER_ONLY=yes" >> $config_mak
   echo "#define CONFIG_USER_ONLY 1" >> $config_h
diff -r 64fb395dc8f1 qemu/qemu-kvm.c
--- a/qemu/qemu-kvm.c	Thu Feb 15 14:36:40 2007 +0000
+++ b/qemu/qemu-kvm.c	Mon Feb 19 18:21:03 2007 -0600
@@ -705,5 +705,40 @@ int kvm_update_debugger(CPUState *env)
     return kvm_guest_debug(kvm_context, 0, &dbg);
 }
 
-
-#endif
+#ifdef CONFIG_KVM
+
+CCTable cc_table[CC_OP_NB];
+
+int code_copy_enabled;
+
+static int nop_flags(void)
+{
+    return 0;
+}
+
+int cpu_gen_code(CPUState *env, TranslationBlock *tb,
+		 int max_code_size, int *gen_code_size_ptr)
+{
+    return -1;
+}
+
+int cpu_restore_state(TranslationBlock *tb,
+		      CPUState *env, unsigned long searched_pc,
+		      void *puc)
+{
+    return -1;
+}
+
+void optimize_flags_init(void)
+{
+    int i;
+
+    for (i = 0; i < CC_OP_NB; i++) {
+	cc_table[i].compute_c = nop_flags;
+	cc_table[i].compute_all = nop_flags;
+    }
+}
+
+#endif
+
+#endif
diff -r 64fb395dc8f1 qemu/target-i386/helper.c
--- a/qemu/target-i386/helper.c	Thu Feb 15 14:36:40 2007 +0000
+++ b/qemu/target-i386/helper.c	Mon Feb 19 18:27:35 2007 -0600
@@ -1594,6 +1594,9 @@ void helper_idivl_EAX_T0(void)
     EDX = (uint32_t)r;
 }
 
+/* GCC 4 has a hard time with this helper */
+
+#ifndef CONFIG_KVM
 void helper_cmpxchg8b(void)
 {
     uint64_t d;
@@ -1611,6 +1614,7 @@ void helper_cmpxchg8b(void)
     }
     CC_SRC = eflags;
 }
+#endif
 
 void helper_cpuid(void)
 {
@@ -2968,6 +2972,9 @@ void helper_verw(void)
     CC_SRC = eflags | CC_Z;
 }
 
+/* GCC 4 has a hard time with the FPU helpers */
+#ifndef CONFIG_KVM
+
 /* FPU helpers */
 
 void helper_fldt_ST0_A0(void)
@@ -3485,6 +3492,7 @@ void helper_fxrstor(target_ulong ptr, in
         }
     }
 }
+#endif
 
 #ifndef USE_X86LDOUBLE
 
diff -r 64fb395dc8f1 qemu/vl.c
--- a/qemu/vl.c	Thu Feb 15 14:36:40 2007 +0000
+++ b/qemu/vl.c	Mon Feb 19 19:03:34 2007 -0600
@@ -7341,8 +7341,13 @@ int main(int argc, char **argv)
 #if USE_KVM
     if (kvm_allowed) {
 	if (kvm_qemu_init() < 0) {
+#ifdef CONFIG_KVM
+	    fprintf(stderr, "Could not initialize KVM\n");
+	    exit(1);
+#else
 	    fprintf(stderr, "Could not initialize KVM, will disable KVM support\n");
 	    kvm_allowed = 0;
+#endif
 	}
     }
 #endif

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [RFC] QEMU KVM target

[Jun Koi]

Howdy Anthony,

> Here's a tiny patch that adds a i386-kvm target.  The main difference
> between the i386-kvm and i386-softmmu target is that the -kvm target
> does not have any of the dyngen infrastructure.  This means that it will
> build with gcc-4.  I know you can do --cc=gcc to use gcc-4 but quite a
> few versions of gcc-4 have trouble with compiling dyngen.

I understand that your approach is to remove the "binary translation"
part of the vanilla qemu, because we dont need it. We only need the
device emulation code of qemu for kvm. Do I understand correctly?

If so, we do not need to depend on gcc3 tricks anymore. Removing the
dependent on gcc3 is really an important achievement.

Thanks,
Jun

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Anthony Liguori]

Jun Koi wrote:
> Howdy Anthony,
>
>> Here's a tiny patch that adds a i386-kvm target.  The main difference
>> between the i386-kvm and i386-softmmu target is that the -kvm target
>> does not have any of the dyngen infrastructure.  This means that it will
>> build with gcc-4.  I know you can do --cc=gcc to use gcc-4 but quite a
>> few versions of gcc-4 have trouble with compiling dyngen.
>
> I understand that your approach is to remove the "binary translation"
> part of the vanilla qemu, because we dont need it. We only need the
> device emulation code of qemu for kvm. Do I understand correctly?

Yup.

Regards,

Anthony Liguori

> If so, we do not need to depend on gcc3 tricks anymore. Removing the
> dependent on gcc3 is really an important achievement.
>
> Thanks,
> Jun
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Avi Kivity]

Anthony Liguori wrote:
> Howdy,
>
> Here's a tiny patch that adds a i386-kvm target.  The main difference 
> between the i386-kvm and i386-softmmu target is that the -kvm target 
> does not have any of the dyngen infrastructure.  This means that it 
> will build with gcc-4.  I know you can do --cc=gcc to use gcc-4 but 
> quite a few versions of gcc-4 have trouble with compiling dyngen.
>
> I also suspect this may prove useful down the road.  What do other 
> people think?  I'm not terribly tied to the i386-kvm name for what 
> it's worth.
>

That kills the -no-kvm switch, which allows a single binary to be used 
both with and without kvm.  Or do you think both target-i386+kvm and 
target-kvm ought to be kept?

My thinking about qemu integration is that kqemu/kvm code needs to be 
abstracted into an API  to reduce the #ifdefing in qemu, and that API 
could call kqemu or kvm as appropriate.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Avi Kivity]

Avi Kivity wrote:
> Anthony Liguori wrote:
>   
>> Howdy,
>>
>> Here's a tiny patch that adds a i386-kvm target.  The main difference 
>> between the i386-kvm and i386-softmmu target is that the -kvm target 
>> does not have any of the dyngen infrastructure.  This means that it 
>> will build with gcc-4.  I know you can do --cc=gcc to use gcc-4 but 
>> quite a few versions of gcc-4 have trouble with compiling dyngen.
>>
>> I also suspect this may prove useful down the road.  What do other 
>> people think?  I'm not terribly tied to the i386-kvm name for what 
>> it's worth.
>>
>>     
>
> That kills the -no-kvm switch, which allows a single binary to be used 
> both with and without kvm.  Or do you think both target-i386+kvm and 
> target-kvm ought to be kept?
>
>   

I meant here: target-i386 (with kvm support) and target-i386-kvm.

> My thinking about qemu integration is that kqemu/kvm code needs to be 
> abstracted into an API  to reduce the #ifdefing in qemu, and that API 
> could call kqemu or kvm as appropriate.
>
>
>   


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Howdy,
>>
>> Here's a tiny patch that adds a i386-kvm target.  The main difference 
>> between the i386-kvm and i386-softmmu target is that the -kvm target 
>> does not have any of the dyngen infrastructure.  This means that it 
>> will build with gcc-4.  I know you can do --cc=gcc to use gcc-4 but 
>> quite a few versions of gcc-4 have trouble with compiling dyngen.
>>
>> I also suspect this may prove useful down the road.  What do other 
>> people think?  I'm not terribly tied to the i386-kvm name for what 
>> it's worth.
>>
>
> That kills the -no-kvm switch, which allows a single binary to be used 
> both with and without kvm.  Or do you think both target-i386+kvm and 
> target-kvm ought to be kept?

I think both should be kept.  I think configure ought to be smart enough 
to figure out if gcc-3 is available and build the appropriate targets.  
Adding the new target is a small enough patch that it won't be offensive 
and should make a lot of users happy.

> My thinking about qemu integration is that kqemu/kvm code needs to be 
> abstracted into an API  to reduce the #ifdefing in qemu, and that API 
> could call kqemu or kvm as appropriate.

That's definitely not a bad idea.


Regards,

Anthony Liguori

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Anthony Liguori]

Avi Kivity wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>  
>>> Howdy,
>>>
>>> Here's a tiny patch that adds a i386-kvm target.  The main 
>>> difference between the i386-kvm and i386-softmmu target is that the 
>>> -kvm target does not have any of the dyngen infrastructure.  This 
>>> means that it will build with gcc-4.  I know you can do --cc=gcc to 
>>> use gcc-4 but quite a few versions of gcc-4 have trouble with 
>>> compiling dyngen.
>>>
>>> I also suspect this may prove useful down the road.  What do other 
>>> people think?  I'm not terribly tied to the i386-kvm name for what 
>>> it's worth.
>>>
>>>     
>>
>> That kills the -no-kvm switch, which allows a single binary to be 
>> used both with and without kvm.  Or do you think both target-i386+kvm 
>> and target-kvm ought to be kept?
>>
>>   
>
> I meant here: target-i386 (with kvm support) and target-i386-kvm.

target-i386 is an architecture.  It can currently generate i386-softmmu, 
i386-user, x86_64-softmmu, x86_64-user.  We're simply adding the ability 
to generate i386-kvm and x86_64-kvm.  I'd like to find another name.

I still want to be able to support kvm/qemu in the normal i386-softmmu.

Regards,

Anthony Liguori

>> My thinking about qemu integration is that kqemu/kvm code needs to be 
>> abstracted into an API  to reduce the #ifdefing in qemu, and that API 
>> could call kqemu or kvm as appropriate.
>>
>>
>>   
>
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Avi Kivity]

Anthony Liguori wrote:
>>>
>>> That kills the -no-kvm switch, which allows a single binary to be 
>>> used both with and without kvm.  Or do you think both 
>>> target-i386+kvm and target-kvm ought to be kept?
>>>
>>>   
>>
>> I meant here: target-i386 (with kvm support) and target-i386-kvm.
>
> target-i386 is an architecture.  It can currently generate 
> i386-softmmu, i386-user, x86_64-softmmu, x86_64-user.  We're simply 
> adding the ability to generate i386-kvm and x86_64-kvm.  I'd like to 
> find another name.
>
> I still want to be able to support kvm/qemu in the normal i386-softmmu.

Thanks, that clears it up.  I'll apply the patch.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>>
>>>> That kills the -no-kvm switch, which allows a single binary to be 
>>>> used both with and without kvm.  Or do you think both 
>>>> target-i386+kvm and target-kvm ought to be kept?
>>>>
>>>>   
>>>
>>> I meant here: target-i386 (with kvm support) and target-i386-kvm.
>>
>> target-i386 is an architecture.  It can currently generate 
>> i386-softmmu, i386-user, x86_64-softmmu, x86_64-user.  We're simply 
>> adding the ability to generate i386-kvm and x86_64-kvm.  I'd like to 
>> find another name.
>>
>> I still want to be able to support kvm/qemu in the normal i386-softmmu.
>
> Thanks, that clears it up.  I'll apply the patch.

Can you wait on that?  I'll submit a better one tonight.  It was just an 
RFC :-)

Regards,

Anthony Liguori


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Avi Kivity]

Anthony Liguori wrote:
>
> Can you wait on that?  I'll submit a better one tonight.  It was just 
> an RFC :-)
>

Ok.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Rusty Russell]

On Tue, 2007-02-20 at 11:55 +0900, Jun Koi wrote:
> Howdy Anthony,
> 
> > Here's a tiny patch that adds a i386-kvm target.  The main difference
> > between the i386-kvm and i386-softmmu target is that the -kvm target
> > does not have any of the dyngen infrastructure.  This means that it will
> > build with gcc-4.  I know you can do --cc=gcc to use gcc-4 but quite a
> > few versions of gcc-4 have trouble with compiling dyngen.
> 
> I understand that your approach is to remove the "binary translation"
> part of the vanilla qemu, because we dont need it. We only need the
> device emulation code of qemu for kvm. Do I understand correctly?
> 
> If so, we do not need to depend on gcc3 tricks anymore. Removing the
> dependent on gcc3 is really an important achievement.

Does your patch still call the binary qemu?  It'd be nice for
distributions to have a real qemu still available as 'qemu', and the
kvm-specific one as something else.

Cheers,
Rusty.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Anthony Liguori]

Rusty Russell wrote:
> On Tue, 2007-02-20 at 11:55 +0900, Jun Koi wrote:
>   
>> Howdy Anthony,
>>
>>     
>>> Here's a tiny patch that adds a i386-kvm target.  The main difference
>>> between the i386-kvm and i386-softmmu target is that the -kvm target
>>> does not have any of the dyngen infrastructure.  This means that it will
>>> build with gcc-4.  I know you can do --cc=gcc to use gcc-4 but quite a
>>> few versions of gcc-4 have trouble with compiling dyngen.
>>>       
>> I understand that your approach is to remove the "binary translation"
>> part of the vanilla qemu, because we dont need it. We only need the
>> device emulation code of qemu for kvm. Do I understand correctly?
>>
>> If so, we do not need to depend on gcc3 tricks anymore. Removing the
>> dependent on gcc3 is really an important achievement.
>>     
>
> Does your patch still call the binary qemu?  It'd be nice for
> distributions to have a real qemu still available as 'qemu', and the
> kvm-specific one as something else.
>   

It calls it qemu-kvm (or qemu-system-x86_64-kvm).  I'd like to find a 
better name, perhaps qemu-system-i386-accel or something.

Regards,

Anthony Liguori

> Cheers,
> Rusty.
>
>
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] QEMU KVM target

[Dylan Taft]

Sweet deal.  I just applied the patch to v14, and compiled with gcc
4.1.1.  Thanks a lot!

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV