Prev: Announce loop-AES-v3.3a file/swap crypto package
Next: [PATCH] OMAP: Devkit8000: Add missing package selection
From: Pekka Enberg on 22 Mar 2010 09:10
Hi Avi,

On Mon, Mar 22, 2010 at 2:49 PM, Avi Kivity <avi(a)redhat.com> wrote:
> Seems like perf is also split, with sysprof being developed outside the
> kernel. �Will you bring sysprof into the kernel? �Will every feature be
> duplicated in prof and sysprof?

I am glad you brought it up! Sysprof was historically outside of the
kernel (with it's own kernel module, actually). While the GUI was
nice, it was much harder to set up compared to oprofile so it wasn't
all that popular. Things improved slightly when Ingo merged the custom
kernel module but the _userspace_ part of sysprof was lagging behind a
bit. I don't know what's the situation now that they've switched over
to perf syscalls but you probably get my point.

It would be nice if the two projects merged but I honestly don't see
any fundamental problem with two (or more) co-existing projects.
Friendly competition will ultimately benefit the users (think KDE and
Gnome here).

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 22 Mar 2010 12:50
On Mon, Mar 22, 2010 at 6:16 PM, Avi Kivity <avi(a)redhat.com> wrote:
>> You simply kept ignoring me when I said that if something can be kept out
>> of the kernel without impacting performance, it should be. �I don't want
>> emergency patches closing some security hole or oops in a kernel symbol
>> server.
>
> Or rather, explained how I am a wicked microkernelist. �The herring were out
> in force today.

Well, if it's not being a "wicked microkernelist" then what is it?
Performance is hardly the only motivation to put things into the
kernel. Think kernel mode-setting and devtmpfs (with the ironic twist
of original devfs being removed from the kernel) here, for example.

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 22 Mar 2010 13:30
Hi Frank,

On Mon, Mar 22, 2010 at 7:17 PM, Frank Ch. Eigler <fche(a)redhat.com> wrote:
> In your very previous paragraphs, you enumerate two separate causes:
> "repository structure" and "development/maintenance process" as being
> sources of "fun". �Please simply accept that the former is considered
> by many as absolutely trivial compared to the latter, and additional
> verbose repetition of your thesis will not change this.

I can accept that many people consider it trivial but the problem is
that we have _real data_ on kmemtrace and now perf that the amount of
contributors is significantly smaller when your code is outside the
kernel repository. Now admittedly both of them are pretty intimate
with the kernel but Ingo's suggestion of putting kvm-qemu in tools/ is
an interesting idea nevertheless.

It's kinda funny to see people argue that having an external
repository is not a problem and that it's not a big deal if building
something from the repository is slightly painful as long as it
doesn't require a PhD when we have _real world_ experience that it
_does_ limit developer base in some cases. Whether or not that applies
to kvm remains to be seen but I've yet to see a convincing argument
why it doesn't.

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 22 Mar 2010 13:40
On 03/22/2010 07:27 PM, Pekka Enberg wrote:
> It's kinda funny to see people argue that having an external
> repository is not a problem and that it's not a big deal if building
> something from the repository is slightly painful as long as it
> doesn't require a PhD when we have _real world_ experience that it
> _does_ limit developer base in some cases. Whether or not that applies
> to kvm remains to be seen but I've yet to see a convincing argument
> why it doesn't.
>

qemu has non-Linux developers. Not all of their contributions are
relevant to kvm but some are. If we pull qemu into tools/kvm, we lose them.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 22 Mar 2010 14:00
Hi Avi,

On Mon, Mar 22, 2010 at 7:32 PM, Avi Kivity <avi(a)redhat.com> wrote:
>> It's kinda funny to see people argue that having an external
>> repository is not a problem and that it's not a big deal if building
>> something from the repository is slightly painful as long as it
>> doesn't require a PhD when we have _real world_ experience that it
>> _does_ limit developer base in some cases. Whether or not that applies
>> to kvm remains to be seen but I've yet to see a convincing argument
>> why it doesn't.
>
> qemu has non-Linux developers. �Not all of their contributions are relevant
> to kvm but some are. �If we pull qemu into tools/kvm, we lose them.

Yeah, you probably would but the hypothesis is that you'd end up with
a bigger net developer base for the _Linux_ version. Now you might not
think that's important but I certainly do and I think Ingo does as
well. ;-)

That said, pulling 400 KLOC of code into the kernel sounds really
excessive. Would we need all that if we just do native virtualization
and no actual emulation?

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Announce loop-AES-v3.3a file/swap crypto package
Next: [PATCH] OMAP: Devkit8000: Add missing package selection