Message-ID: <4615086C.9060306@us.ibm.com>
Date:	Thu, 05 Apr 2007 09:32:12 -0500
From:	Anthony Liguori <aliguori@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Rusty Russell <rusty@...tcorp.com.au>,
	kvm-devel@...ts.sourceforge.net, netdev <netdev@...r.kernel.org>
Subject: Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work

Ingo Molnar wrote:
> * Rusty Russell <rusty@...tcorp.com.au> wrote:
>
>   
>> It's easier to write a kernel-space network driver, but it's not 
>> obviously the right thing to do until we can show that an efficient 
>> packet-level userspace interface isn't possible.  I don't think that's 
>> been done, and it would be interesting to try.
>>     
>
> yes, i agree in theory, but IMO this is largely beside the point. What 
> matters most for developing a project is _the quality of the codebase_. 
> That attracts developers, developers improve the code, which then 
> attracts users, which attracts more developers, etc., etc. As long as 
> the quality of the codebase is maintained, this is a self-sustaining 
> process. You've seen that happen with Linux. [ And of course, the 
> crutial step #0 is: a sane, open-minded maintainer with good taste ;-) ]
>
> qemu's code quality is not really suitable for that basic OSS model, in 
> my opinion.

I think you may want to step off your high horse there.  QEMU's code may 
not be Linux kernel quality but it's certainly not anywhere near the 
worst that is out there.  Linux is over decade old.  QEMU is only around 
3 years old.  Did Linux have extremely high quality code in 1994?  
Instead of posting code snippets to LKML, it would be much more 
constructive to post patches to qemu-devel.  It's not like the QEMU 
maintainers are actively ignoring your efforts to improve the code.

> but architectural issues aside (ignoring that the kernel _is_ the best 
> place to do this particular of stuff),

Right.  We don't put things in the kernel just because we don't like the 
way the userspace code is written.  If that logic was valid, then Linus 
would be working on moving all of Gnome into the kernel.

This discussion has two parts.  The first is whether or not the kernel 
is the right place for a paravirtual network driver backend.  My current 
believe is that we could not get enough performance from something like 
tun to do it in userspace.  I also believe that we could improve tun (or 
create a replacement) so that we could implement a PV network driver 
backend in userspace.  Admittedly, I'm not an expert in networking 
though so I could be wrong here.

The second part is whether the platform devices should go in the 
kernel.  I agree with you that having the PIT in the kernel is probably 
a good idea.  I also agree that we probably have no choice but to move 
the APIC into the kernel (not for PV drivers, but for TPR performance 
and SMP support).

Regards,

Anthony Liguori

>  this question is still mainly 
> dominated by the basic question of code quality. I'd rather move 
> something into the Linux kernel, enforce its code quality that way, and 
> _then_ add whatever clean infrastructure is needed to push it back into 
> user-space again (into a different codebase), than having to hack the 
> monolithic 200 KLOC+ qemu codebase that is shackled with support for 
> tons of arcane architectures nobody uses and tons of arcane OS variants 
> that no-one cares about. Now qemu is a very important enabler and 
> platform-reference-implementation for KVM to fall back to, but it's not 
> the place to put crutial new code into, at least currently.
>
> 	Ingo
>   

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists