* Ingo Molnar wrote:
> I'll remove it if Linus insists on it, but I think you guys
> are putting form before substance and utility :-(
So, just to bring this to a conclusion, obviously Linus is
insisting on it, so I've removed tools/kvm from tip:auto-latest,
by going back from the daily
* Ingo Molnar mi...@kernel.org wrote:
I'll remove it if Linus insists on it, but I think you guys
are putting form before substance and utility :-(
So, just to bring this to a conclusion, obviously Linus is
insisting on it, so I've removed tools/kvm from tip:auto-latest,
by going back from
On 02/13/2013 02:56 AM, Pekka Enberg wrote:
On Wed, Feb 13, 2013 at 10:23 AM, Paolo Bonzini wrote:
Il 12/02/2013 10:52, Ingo Molnar ha scritto:
Check the list I gave (unmodified):
"- Pekka listed new virtio drivers that were done via tools/kvm.
vhost-scsi got in first in tools/kvm, but
On 02/13/2013 02:56 AM, Pekka Enberg wrote:
On Wed, Feb 13, 2013 at 10:23 AM, Paolo Bonzinipbonz...@redhat.com wrote:
Il 12/02/2013 10:52, Ingo Molnar ha scritto:
Check the list I gave (unmodified):
- Pekka listed new virtio drivers that were done via tools/kvm.
vhost-scsi got in first in
* Pekka Enberg wrote:
> I think Ingo confused virtio and vhost. IIRC, Asias developed
> vhost-blk using tools/kvm.
Erm, indeed - sorry.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Wed, Feb 13, 2013 at 10:23 AM, Paolo Bonzini wrote:
> Il 12/02/2013 10:52, Ingo Molnar ha scritto:
>> Check the list I gave (unmodified):
>>
>> "- Pekka listed new virtio drivers that were done via tools/kvm.
>
> vhost-scsi got in first in tools/kvm, but out-of-tree patches had
> existed for
Il 12/02/2013 10:52, Ingo Molnar ha scritto:
> Check the list I gave (unmodified):
>
> "- Pekka listed new virtio drivers that were done via tools/kvm.
vhost-scsi got in first in tools/kvm, but out-of-tree patches had
existed for QEMU for more than a year. It was developed with QEMU.
> -
Il 12/02/2013 10:52, Ingo Molnar ha scritto:
Check the list I gave (unmodified):
- Pekka listed new virtio drivers that were done via tools/kvm.
vhost-scsi got in first in tools/kvm, but out-of-tree patches had
existed for QEMU for more than a year. It was developed with QEMU.
- Pekka
On Wed, Feb 13, 2013 at 10:23 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 12/02/2013 10:52, Ingo Molnar ha scritto:
Check the list I gave (unmodified):
- Pekka listed new virtio drivers that were done via tools/kvm.
vhost-scsi got in first in tools/kvm, but out-of-tree patches had
* Pekka Enberg penb...@kernel.org wrote:
I think Ingo confused virtio and vhost. IIRC, Asias developed
vhost-blk using tools/kvm.
Erm, indeed - sorry.
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
* Linus Torvalds wrote:
> On Mon, Feb 11, 2013 at 9:58 AM, Ingo Molnar wrote:
> >
> > So basically Pekka optimistically thought it's an eventual
> > 'tit for tat', a constant stream of benefits to the kernel,
> > in the hope of finding a home in the upstream kernel which
> > would further
* Linus Torvalds torva...@linux-foundation.org wrote:
On Mon, Feb 11, 2013 at 9:58 AM, Ingo Molnar mi...@kernel.org wrote:
So basically Pekka optimistically thought it's an eventual
'tit for tat', a constant stream of benefits to the kernel,
in the hope of finding a home in the
On Mon, Feb 11, 2013 at 9:58 AM, Ingo Molnar wrote:
>
> So basically Pekka optimistically thought it's an eventual 'tit
> for tat', a constant stream of benefits to the kernel, in the
> hope of finding a home in the upstream kernel which would
> further help both projects. The kernel wants to
* Linus Torvalds wrote:
> On Feb 11, 2013 9:28 AM, "Ingo Molnar" wrote:
>
> > How on earth can anyone, against all that evidence, still
> > claim that it's a net minus?
>
> Because I don't think there is any reason for mixing up the
> projects. Why do you not just make it separate?
* David Woodhouse wrote:
> On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
> > To use another, perhaps more applicable analogy:
> >
> > If one has the choice to start a new business in the U.S., it
> > would be reasonable to do that. There's a lot of supporting
> > infrastructure,
On 02/11/2013 08:34 AM, Linus Torvalds wrote:
On Mon, Feb 11, 2013 at 5:18 AM, David Woodhouse wrote:
That's complete nonsense. If you want to use pieces of the kernel
infrastructure, then just *take* them. There are loads of projects which
use the kernel config tools, for example. There's no
* Linus Torvalds wrote:
> On Mon, Feb 11, 2013 at 4:26 AM, Ingo Molnar wrote:
> >
> > If you are asking whether it is critical for the kernel
> > project to have tools/kvm/ integrated then it isn't. The
> > kernel will live just fine without it, even if that decision
> > is a mistake.
>
>
Linus, will you help to the project ?
Talk to Linaro guys.
On Mon, Feb 11, 2013 at 6:46 PM, David Woodhouse wrote:
> On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
>> On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar wrote:
>> > IIRC Windows support for kmvtool is work in progress - some
>>
On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
> On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar wrote:
> > IIRC Windows support for kmvtool is work in progress - some
> > patches already got applied.
>
> People are working on SeaBIOS support which is just one part of
> running Windows. But
On Mon, Feb 11, 2013 at 5:18 AM, David Woodhouse wrote:
>
> That's complete nonsense. If you want to use pieces of the kernel
> infrastructure, then just *take* them. There are loads of projects which
> use the kernel config tools, for example. There's no need to be *in* the
> kernel repo.
On Mon, Feb 11, 2013 at 4:26 AM, Ingo Molnar wrote:
>
> If you are asking whether it is critical for the kernel project
> to have tools/kvm/ integrated then it isn't. The kernel will
> live just fine without it, even if that decision is a mistake.
You go on to explain how this helps kvmtool, and
On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar wrote:
> IIRC Windows support for kmvtool is work in progress - some
> patches already got applied.
People are working on SeaBIOS support which is just one part of
running Windows. But yeah, we'll hopefully support non-Linux guest at
some point.
On
[quote]the ultimate goal being to make this new socket family
hypervisor-neutral[/quote]
That was from vmware.
If somebody will make something generic, to please xen, kvm, vmware,
and others in an 15 to 20 years time...
Then a tool like this will be accepted ?
Linus, you know this tool was only
On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
> To use another, perhaps more applicable analogy:
>
> If one has the choice to start a new business in the U.S., it
> would be reasonable to do that. There's a lot of supporting
> infrastructure, trust, distribution, standards, enforcement
* Ingo Molnar wrote:
> [...]
>
> - he ended up gradually validating whether lockdep could be
>ported to user-space. He first used 'messy' integration:
>kernel/lockdep.c hacked up badly and linked directly into
>user-space app. Then he did 'clean' integration: some
>
* Theodore Ts'o wrote:
> I completely agree with Linus here; in fact, the main reason
> why it's important to keep userspace tools outside of the
> kernel is that it keeps us careful about interface design.
We have first hand experience there: tools/perf/.
None of the predicted extreme
* Linus Torvalds wrote:
> On Sun, Feb 10, 2013 at 6:39 AM, Pekka Enberg wrote:
> >
> > The main argument for merging into the main kernel
> > repository has always been that (we think) it improves the
> > kernel because significant amount of development is directly
> > linked to kernel code
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sun, Feb 10, 2013 at 6:39 AM, Pekka Enberg penb...@kernel.org wrote:
The main argument for merging into the main kernel
repository has always been that (we think) it improves the
kernel because significant amount of development
* Theodore Ts'o ty...@mit.edu wrote:
I completely agree with Linus here; in fact, the main reason
why it's important to keep userspace tools outside of the
kernel is that it keeps us careful about interface design.
We have first hand experience there: tools/perf/.
None of the predicted
* Ingo Molnar mi...@kernel.org wrote:
[...]
- he ended up gradually validating whether lockdep could be
ported to user-space. He first used 'messy' integration:
kernel/lockdep.c hacked up badly and linked directly into
user-space app. Then he did 'clean' integration: some
On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
To use another, perhaps more applicable analogy:
If one has the choice to start a new business in the U.S., it
would be reasonable to do that. There's a lot of supporting
infrastructure, trust, distribution, standards, enforcement
[quote]the ultimate goal being to make this new socket family
hypervisor-neutral[/quote]
That was from vmware.
If somebody will make something generic, to please xen, kvm, vmware,
and others in an 15 to 20 years time...
Then a tool like this will be accepted ?
Linus, you know this tool was only
On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar mi...@kernel.org wrote:
IIRC Windows support for kmvtool is work in progress - some
patches already got applied.
People are working on SeaBIOS support which is just one part of
running Windows. But yeah, we'll hopefully support non-Linux guest at
On Mon, Feb 11, 2013 at 4:26 AM, Ingo Molnar mi...@kernel.org wrote:
If you are asking whether it is critical for the kernel project
to have tools/kvm/ integrated then it isn't. The kernel will
live just fine without it, even if that decision is a mistake.
You go on to explain how this helps
On Mon, Feb 11, 2013 at 5:18 AM, David Woodhouse dw...@infradead.org wrote:
That's complete nonsense. If you want to use pieces of the kernel
infrastructure, then just *take* them. There are loads of projects which
use the kernel config tools, for example. There's no need to be *in* the
On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar mi...@kernel.org wrote:
IIRC Windows support for kmvtool is work in progress - some
patches already got applied.
People are working on SeaBIOS support which is just one part of
running
Linus, will you help to the project ?
Talk to Linaro guys.
On Mon, Feb 11, 2013 at 6:46 PM, David Woodhouse dw...@infradead.org wrote:
On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar mi...@kernel.org wrote:
IIRC Windows support for kmvtool
* Linus Torvalds torva...@linux-foundation.org wrote:
On Mon, Feb 11, 2013 at 4:26 AM, Ingo Molnar mi...@kernel.org wrote:
If you are asking whether it is critical for the kernel
project to have tools/kvm/ integrated then it isn't. The
kernel will live just fine without it, even if
On 02/11/2013 08:34 AM, Linus Torvalds wrote:
On Mon, Feb 11, 2013 at 5:18 AM, David Woodhouse dw...@infradead.org wrote:
That's complete nonsense. If you want to use pieces of the kernel
infrastructure, then just *take* them. There are loads of projects which
use the kernel config tools, for
* David Woodhouse dw...@infradead.org wrote:
On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
To use another, perhaps more applicable analogy:
If one has the choice to start a new business in the U.S., it
would be reasonable to do that. There's a lot of supporting
* Linus Torvalds torva...@linux-foundation.org wrote:
On Feb 11, 2013 9:28 AM, Ingo Molnar mi...@kernel.org wrote:
How on earth can anyone, against all that evidence, still
claim that it's a net minus?
Because I don't think there is any reason for mixing up the
projects. Why do you
On Mon, Feb 11, 2013 at 9:58 AM, Ingo Molnar mi...@kernel.org wrote:
So basically Pekka optimistically thought it's an eventual 'tit
for tat', a constant stream of benefits to the kernel, in the
hope of finding a home in the upstream kernel which would
further help both projects. The kernel
On Sun, Feb 10, 2013 at 06:57:41AM +1100, Linus Torvalds wrote:
> THAT is my main contention. I told you why I think it's actually
> actively untrue. You claim it helps, but what is it about kvmtool that
> makes it so magically helpful to be inside the kernel repository? What
> is it about this
On Sun, Feb 10, 2013 at 6:39 AM, Pekka Enberg wrote:
>
> The main argument for merging into the main kernel repository has always been
> that (we think) it improves the kernel because significant amount of
> development is directly linked to kernel code (think KVM ARM port here, for
> example).
On Sat, Feb 9, 2013 at 8:07 PM, Linus Torvalds
wrote:
> Everything you said was about how it's more convenient for you and
> Ingo, not at all about why it should be better for anybody else. You
> haven't bothered to even try making it an external project, so it
> doesn't compile that way. You're
You do realize that none of your arguments touched the "why should
Linus merge the tree" question at all?
Everything you said was about how it's more convenient for you and
Ingo, not at all about why it should be better for anybody else. You
haven't bothered to even try making it an external
On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
wrote:
> Quite frankly, that's just optimizing for the wrong case.
I obviously don't agree. I'm fairly sure there wouldn't be a kvmtool
that supports x86, PPC64, ARM, and all the virtio drivers had we not
optimized for making development for kernel
On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Quite frankly, that's just optimizing for the wrong case.
I obviously don't agree. I'm fairly sure there wouldn't be a kvmtool
that supports x86, PPC64, ARM, and all the virtio drivers had we not
optimized for
You do realize that none of your arguments touched the why should
Linus merge the tree question at all?
Everything you said was about how it's more convenient for you and
Ingo, not at all about why it should be better for anybody else. You
haven't bothered to even try making it an external
On Sat, Feb 9, 2013 at 8:07 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Everything you said was about how it's more convenient for you and
Ingo, not at all about why it should be better for anybody else. You
haven't bothered to even try making it an external project, so it
doesn't
On Sun, Feb 10, 2013 at 6:39 AM, Pekka Enberg penb...@kernel.org wrote:
The main argument for merging into the main kernel repository has always been
that (we think) it improves the kernel because significant amount of
development is directly linked to kernel code (think KVM ARM port here, for
On Sun, Feb 10, 2013 at 06:57:41AM +1100, Linus Torvalds wrote:
THAT is my main contention. I told you why I think it's actually
actively untrue. You claim it helps, but what is it about kvmtool that
makes it so magically helpful to be inside the kernel repository? What
is it about this that
On Sat, Feb 9, 2013 at 10:57 AM, Pekka Enberg wrote:
>
> And yes, you are absolutely correct that living in the kernel tree is
> suboptimal for the casual user. However, it's a trade-off to make
> tools/kvm *development* easier especially when you need to touch both
> kernel and userspace code.
Linus,
I'm going to go out on a limb here and say that this might the odd out
case that's not really supposed to happen where *you* are just WRONG,
CRAZY, and IGNORING REALITY.
On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds
wrote:
> I think merging it would be an active mistake, and would just
On Sat, Feb 9, 2013 at 1:55 AM, Ingo Molnar wrote:
>
> I'll remove it if Linus insists on it, but I think you guys are
> putting form before substance and utility :-(
No. Your pull requests are just illogical. I have yet to see a single
reason why it should be merged.
I *thought* "ease of use"
* Stephen Rothwell wrote:
> Hi Ingo,
>
> On Wed, 6 Feb 2013 22:46:46 +0100 Ingo Molnar wrote:
> >
> > Pekka still intends to send it in the next merge window AFAIK,
>
> That has been true since v3.2 :-(
Yes, and it's improving rather nicely - but was not
useful/interesting enough (yet)
* Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Ingo,
On Wed, 6 Feb 2013 22:46:46 +0100 Ingo Molnar mi...@kernel.org wrote:
Pekka still intends to send it in the next merge window AFAIK,
That has been true since v3.2 :-(
Yes, and it's improving rather nicely - but was not
On Sat, Feb 9, 2013 at 1:55 AM, Ingo Molnar mi...@kernel.org wrote:
I'll remove it if Linus insists on it, but I think you guys are
putting form before substance and utility :-(
No. Your pull requests are just illogical. I have yet to see a single
reason why it should be merged.
I *thought*
Linus,
I'm going to go out on a limb here and say that this might the odd out
case that's not really supposed to happen where *you* are just WRONG,
CRAZY, and IGNORING REALITY.
On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
I think merging it would be an
On Sat, Feb 9, 2013 at 10:57 AM, Pekka Enberg penb...@kernel.org wrote:
And yes, you are absolutely correct that living in the kernel tree is
suboptimal for the casual user. However, it's a trade-off to make
tools/kvm *development* easier especially when you need to touch both
kernel and
Hi,
On Wed, 06 Feb 2013 13:55:08 -0800 "H. Peter Anvin" wrote:
>
> So why don't we let Linus either accept and reject it for the 3.9 merge,
> but it rejected, we drop it from linux-next until such time as Linus'
> objections have been addressed?
It has been in linux-next since before v3.2. It
Hi Ingo,
On Wed, 6 Feb 2013 22:46:46 +0100 Ingo Molnar wrote:
>
> Pekka still intends to send it in the next merge window AFAIK,
That has been true since v3.2 :-(
> and I use it for testing rather frequently so I'm not going to
> remove it from my tree for the time being.
I didn't ask you
Hi Ingo,
On Wed, 6 Feb 2013 22:46:46 +0100 Ingo Molnar mi...@kernel.org wrote:
Pekka still intends to send it in the next merge window AFAIK,
That has been true since v3.2 :-(
and I use it for testing rather frequently so I'm not going to
remove it from my tree for the time being.
I
Hi,
On Wed, 06 Feb 2013 13:55:08 -0800 H. Peter Anvin h...@zytor.com wrote:
So why don't we let Linus either accept and reject it for the 3.9 merge,
but it rejected, we drop it from linux-next until such time as Linus'
objections have been addressed?
It has been in linux-next since before
On 02/06/2013 01:46 PM, Ingo Molnar wrote:
>>
>> Linus has said that he will not take the kvmtool tree in its
>> current form, but would prefer that it be a separate project,
>> so I should really drop it from linux-next (and ask the tip
>> guys to remove it from their auto-latest branch).
>>
* Stephen Rothwell wrote:
> Hi David,
>
> On Wed, 6 Feb 2013 12:12:57 -0800 (PST) David Rientjes
> wrote:
> >
> > On Wed, 6 Feb 2013, Pekka Enberg wrote:
> >
> > > > Yeah, that's a good idea - I think Pekka can apply that change
> > > > just fine to help anyone doing merges - I don't think
Hi David,
On Wed, 6 Feb 2013 12:12:57 -0800 (PST) David Rientjes
wrote:
>
> On Wed, 6 Feb 2013, Pekka Enberg wrote:
>
> > > Yeah, that's a good idea - I think Pekka can apply that change
> > > just fine to help anyone doing merges - I don't think kconfig
> > > treats it as a fatal error.
> >
Hi David,
On Wed, 6 Feb 2013 12:12:57 -0800 (PST) David Rientjes rient...@google.com
wrote:
On Wed, 6 Feb 2013, Pekka Enberg wrote:
Yeah, that's a good idea - I think Pekka can apply that change
just fine to help anyone doing merges - I don't think kconfig
treats it as a fatal
* Stephen Rothwell s...@canb.auug.org.au wrote:
Hi David,
On Wed, 6 Feb 2013 12:12:57 -0800 (PST) David Rientjes rient...@google.com
wrote:
On Wed, 6 Feb 2013, Pekka Enberg wrote:
Yeah, that's a good idea - I think Pekka can apply that change
just fine to help anyone doing
On 02/06/2013 01:46 PM, Ingo Molnar wrote:
Linus has said that he will not take the kvmtool tree in its
current form, but would prefer that it be a separate project,
so I should really drop it from linux-next (and ask the tip
guys to remove it from their auto-latest branch).
I have
70 matches
Mail list logo
