Ingo Molnar wrote:
* Rusty Russell <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
