* 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. It has been a mostly one-man show for a long time with
various hostile forks, bin-only kernel module and other actions that
easily poison an OSS project.
the result is not surprising: important portions of qemu have grown into
a hard to hack, hard to maintain codebase with poor code quality, with
gems like:
#ifdef _WIN32
void CALLBACK host_alarm_handler(UINT uTimerID, UINT uMsg,
DWORD_PTR dwUser, DWORD_PTR dw1, DWORD_PTR
dw2)
#else
static void host_alarm_handler(int host_signum)
#endif
{
#if 0
#define DISP_FREQ 1000
and that's not just some random driver - this is _the_ main central
timer code of qemu.
so right now the only option for a clean codebase is the KVM in-kernel
code. It's clean and sweet and integrates nicely into the rest of the
kernel. The kernel is also obviously the final place where most
virtualization technologies want to show up because it's the entity that
is the closest to the guest context: we _dont_ want to _force_ network
traffic (let alone interrupt handling) through a userspace context, only
if the functionality of the task absolutely requires it. (but in most
cases we'll try to come up with a maximally flexible scheme that can
just drive things straight via the kernel. netfilter/iptables isnt in
user-space either, partly for that reason.)
but architectural issues aside (ignoring that the kernel _is_ the best
place to do this particular of stuff), 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
