On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
would be doing and what he expects from it. Basically he wants a
small and simple tool he and other developers can run to try out and
see if the kernel they just built actually works.
Fortunately, QEMU can do that today already! T
On 2012-05-11 10:42, Alexander Graf wrote:
>
> On 06.11.2011, at 14:54, Jan Kiszka wrote:
>
>> On 2011-08-24 23:38, Alexander Graf wrote:
>>> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
>>> would be doing and what he expects from it. Basically he wants a
>>> small and simp
On 06.11.2011, at 14:54, Jan Kiszka wrote:
> On 2011-08-24 23:38, Alexander Graf wrote:
>> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
>> would be doing and what he expects from it. Basically he wants a
>> small and simple tool he and other developers can run to try out an
On Tue, 8 Nov 2011, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
> > * Vince Weaver wrote:
> > > as mentioned before I have my own perf_event test suite with 20+ tests.
> > > http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.h
On 11/08/2011 07:34 PM, Alexander Graf wrote:
>>
>>> It could work with a btrfs snapshot, but not everyone uses that.
>> Or LVM snapshot. Either way, just reusing the root fs without care
>> is a dumb idea, and I really don't want any tool or script that
>> encurages such braindead behaviour in th
On 11/08/2011 03:59 PM, Christoph Hellwig wrote:
On Tue, Nov 08, 2011 at 04:57:04PM +0200, Avi Kivity wrote:
Running qemu -snapshot on the actual root block device is the only
safe way to reuse the host installation, although it gets a bit
complicated if people have multiple devices mounted into
On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
> On 11/06/2011 03:35 AM, Alexander Graf wrote:
> > To quickly get going, just execute the following as user:
> >
> > $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
> >
> > This will drop you into a shell on your rootfs.
> >
>
>
On Tue, Nov 08, 2011 at 04:57:04PM +0200, Avi Kivity wrote:
> > Running qemu -snapshot on the actual root block device is the only
> > safe way to reuse the host installation, although it gets a bit
> > complicated if people have multiple devices mounted into the namespace.
>
> How is -snapshot an
On Tue, Nov 08, 2011 at 05:26:03PM +0200, Pekka Enberg wrote:
> On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig wrote:
> > Nevermind that running virtfs as a rootfs is a really dumb idea. ?You
> > do now want to run a VM that has a rootfs that gets changed all the
> > time behind your back.
>
>
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig wrote:
> Nevermind that running virtfs as a rootfs is a really dumb idea. You
> do now want to run a VM that has a rootfs that gets changed all the
> time behind your back.
It's rootfs binaries that are shared, not configuration. It's
unfortunate
On 2011-11-08 15:52, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
>> On 11/06/2011 03:35 AM, Alexander Graf wrote:
>>> To quickly get going, just execute the following as user:
>>>
>>> $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>>>
>>> This wi
On 11/08/2011 04:52 PM, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
> > On 11/06/2011 03:35 AM, Alexander Graf wrote:
> > > To quickly get going, just execute the following as user:
> > >
> > > $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
> > >
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
>> On 11/06/2011 03:35 AM, Alexander Graf wrote:
>> > To quickly get going, just execute the following as user:
>> >
>> > $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
On 11/06/2011 03:35 AM, Alexander Graf wrote:
> To quickly get going, just execute the following as user:
>
> $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>
> This will drop you into a shell on your rootfs.
>
Doesn't work on Fedora 15. F15's qemu-kvm doesn't have -machine or
-virtfs.
On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak wrote:
>> I don't know if it makes sense to merge the tools you've mentioned above.
>> My gut feeling is that it's probably not reasonable - there's already a
>> community working on it with their own development process and coding
>> style. I don't think
On Mon, Nov 07, 2011 at 03:12:28PM +0200, Pekka Enberg wrote:
> On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o wrote:
> > I don't think perf should be used as a precendent that now argues that
> > any new kernel utility should be moved into the kernel sources. Does
> > it make sense to move all of moun
Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
> * Vince Weaver wrote:
> > as mentioned before I have my own perf_event test suite with 20+ tests.
> > http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html
> That should probably be moved into perf test. Arnaldo
* Vince Weaver wrote:
> On Mon, 7 Nov 2011, Ingo Molnar wrote:
> > I think we needed to do only one revert along the way in the past
> > two years, to fix an unintended ABI breakage in PowerTop.
> > Considering the total complexity of the perf ABI our
> > compatibility track record is *very*
On Mon, 7 Nov 2011, Ingo Molnar wrote:
> I think we needed to do only one revert along the way in the past two
> years, to fix an unintended ABI breakage in PowerTop. Considering the
> total complexity of the perf ABI our compatibility track record is
> *very* good.
There have been more breakag
On Nov 7, 2011, at 5:19 PM, Anthony Liguori wrote:
>
> The kernel ecosystem does not have to be limited to linux.git. There could
> be a process to be a "kernel.org project" for projects that fit a certain set
> of criteria. These projects could all share the Linux kernel release cadence
>
On 11/07/2011 03:36 PM, Pekka Enberg wrote:
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o wrote:
Personally, I consider code that runs in userspace as a pretty bright
line, as being "not kernel code", and while perhaps things like
initramfs and the crazy ideas people have had in the past o
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o wrote:
> Personally, I consider code that runs in userspace as a pretty bright
> line, as being "not kernel code", and while perhaps things like
> initramfs and the crazy ideas people have had in the past of moving
> stuff out of kernel/init.c int
On Mon, Nov 07, 2011 at 10:09:34PM +0200, Pekka Enberg wrote:
>
> I guess for perf ABI, "perf test" is the closest thing to a
> specification so if your application is using something that's not
> covered by it, you might be in trouble.
I don't believe there's ever been any guarantee that "perf t
On Mon, Nov 07, 2011 at 09:53:28PM +0200, Pekka Enberg wrote:
>
> I'm sure perf developers break the ABI sometimes - that happens
> elsewhere in the kernel as well. However, Ted claimed that perf
> developers use tools/perf as an excuse to break the ABI _on purpose_
> which is something I have har
On Mon, 7 Nov 2011, Frank Ch. Eigler wrote:
The ABI design allows for that kind of flexible extensibility, and
it's one of its major advantages.
What we *cannot* protect against is you relying on obscure details of
the ABI [...]
Is there some documentation that clearly spells out which parts o
Ingo Molnar writes:
> [...]
>> It's problem enough that there's no way to know what version of the
>> perf_event abi you are running against and we have to guess based
>> on kernel version. This gets "fun" because all of the vendors have
>> backported seemingly random chunks of perf_event cod
On Mon, 7 Nov 2011, Pekka Enberg wrote:
>> I've never heard ABI incompatibility used as an argument for perf. Ingo?
On Mon, Nov 7, 2011 at 7:03 PM, Vince Weaver wrote:
> Never overtly. They're too clever for that.
If you want me to take you seriously, spare me from the conspiracy theories, OK?
* Vince Weaver wrote:
> On Mon, 7 Nov 2011, Pekka Enberg wrote:
>
> > I've never heard ABI incompatibility used as an argument for
> > perf. Ingo?
Correct, the ABI has been designed in a way to make it really hard to
break the ABI via either directed backports or other mess-ups.
The ABI is
On Mon, 7 Nov 2011, Pekka Enberg wrote:
> I've never heard ABI incompatibility used as an argument for perf. Ingo?
Never overtly. They're too clever for that.
In any case, as a primary developer of a library (PAPI) that uses the
perf_events ABI I have to say that having perf in the kernel has
I know kgdb can test kernel,but I haven't succeed .
-- Original --
From: "Pekka Enberg";
Date: 2011年11月7日(星期一) 下午4:57
To: "Paolo Bonzini";
Cc: "Alexander Graf"; "k...@vger.kernel.org list"; "qemu-devel Developers";
"linux-ker...@vger.kernel.org List"; "Blue S
On 11/07/2011 05:57 AM, Ingo Molnar wrote:
* Pekka Enberg wrote:
On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
It's not just about code, it's as much about culture and development process.
Indeed. The BSDs have both kernel and the base system in a single
repository. There are probably good re
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o wrote:
> I don't think perf should be used as a precendent that now argues that
> any new kernel utility should be moved into the kernel sources. Does
> it make sense to move all of mount, fsck, login, etc., into the kernel
> sources? There are far more k
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o wrote:
> Perf was IMHO an overreaction caused by the fact that systemtap and
> oprofile people packaged and released the sources in a way that kernel
> developers didn't like.
>
> I don't think perf should be used as a precendent that now argues that
> any
On Mon, Nov 07, 2011 at 02:42:57PM +0200, Pekka Enberg wrote:
> On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o wrote:
> > Because it's a stupid, idiotic thing to do.
>
> The discussion is turning into whether or not linux/tools makes sense
> or not. I wish you guys would have had it before perf was mer
On 11/07/2011 02:29 PM, Pekka Enberg wrote:
> Hi Avi,
>
> On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity wrote:
> >> tools/power was merged in just 2 versions ago, do you think that
> >> merging that was a mistake?
> >
> > Things like tools/power may make sense, most of the code is tied to the
> > ker
On Mon, Nov 07, 2011 at 02:29:45PM +0200, Pekka Enberg wrote:
> So what do you think about perf then? The amount of code that talks to
> the kernel is much smaller than that of the KVM tool.
I think it's a mess, because it's never clear whether perf needs to be
upgraded when I upgrade the kernel,
Hi Ted,
On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o wrote:
> And the same problems will exist with kvm-tool. What if you need to
> release a new version of kvm-tool? Does that mean that you have to
> release a new set of kernel binaries? It's a mess, and there's a
> reason why we don't have glibc
Hi Avi,
On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity wrote:
>> tools/power was merged in just 2 versions ago, do you think that
>> merging that was a mistake?
>
> Things like tools/power may make sense, most of the code is tied to the
> kernel interfaces. tools/kvm is 20k lines and is likely to be
On Mon, Nov 07, 2011 at 01:08:50PM +0100, Gerd Hoffmann wrote:
>
> perf *is* an exception today.
>
> It might make sense to change that. But IMHO it only makes sense if
> there is a really broad agreement on it and other core stuff moves into
> the kernel too. Then you'll be able to get advanta
On 11/07/2011 12:30 PM, Sasha Levin wrote:
> On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> >> It's not just about code, it's as much about culture and development
> >> process.
> >
> > Indeed. The BSDs have both kernel and the base system in a single
> > repository. There
On Mon, Nov 7, 2011 at 2:18 PM, Gerd Hoffmann wrote:
> tools/ lacks a separation into "kernel hacker's testing+debugging
> toolbox" and "userspace tools". It lacks proper buildsystem integration
> for the userspace tools, there is no "make tools" and also no "make
> tools_install". Silently drop
On 11/07/11 12:44, Pekka Enberg wrote:
> On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini wrote:
>> Indeed I do not see any advantage, since all the interfaces they use are
>> stable anyway (sysfs, msr.ko).
>>
>> If they had gone in x86info, for example, my distro (F16, not exactly
>> conservative) w
On 11/07/11 12:34, Pekka Enberg wrote:
> On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
>>> It's not just about code, it's as much about culture and development
>>> process.
>>
>> Indeed. The BSDs have both kernel and the base system in a single
>> repository. There are probably good reasons for (and a
* Pekka Enberg wrote:
> On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
> >>It's not just about code, it's as much about culture and development
> >>process.
> >
> >Indeed. The BSDs have both kernel and the base system in a single
> >repository. There are probably good reasons for (and against) it.
Am 07.11.2011 12:38, schrieb Pekka Enberg:
> On Mon, 7 Nov 2011, Kevin Wolf wrote:
>> Makes it a lot less hackable for me unless you want to restrict the set
>> of potential developers to Linux kernel developers...
>
> We're not restricting potential developers to Linux kernel folks. We're
> maki
On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini wrote:
> Indeed I do not see any advantage, since all the interfaces they use are
> stable anyway (sysfs, msr.ko).
>
> If they had gone in x86info, for example, my distro (F16, not exactly
> conservative) would have likely picked those tools up already
On Mon, 7 Nov 2011, Kevin Wolf wrote:
Makes it a lot less hackable for me unless you want to restrict the set
of potential developers to Linux kernel developers...
We're not restricting potential developers to Linux kernel folks. We're
making it easy for them because we believe that the KVM to
On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
It's not just about code, it's as much about culture and development process.
Indeed. The BSDs have both kernel and the base system in a single
repository. There are probably good reasons for (and against) it.
In Linux we don't have that culture. No
On 11/07/2011 11:30 AM, Sasha Levin wrote:
> In Linux we don't have that culture. No tool (except perf) lives in the
> kernel repo. I fail to see why kvm-tool is that much different from
> udev, util-linux, iproute, filesystem tools, that it should be included.
tools/power was merged in jus
On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann wrote:
> Hi,
>
>> It's not just about code, it's as much about culture and development process.
>
> Indeed. The BSDs have both kernel and the base system in a single
> repository. There are probably good reasons for (and against) it.
>
> In Linux w
Am 06.11.2011 19:31, schrieb Ted Ts'o:
> On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
>> I'm quite happy with KVM tool and hope they continue working on it.
>> My only real wish is that they wouldn't copy QEMU so much and would
>> try bolder things that are fundamentally differe
Hi,
> It's not just about code, it's as much about culture and development process.
Indeed. The BSDs have both kernel and the base system in a single
repository. There are probably good reasons for (and against) it.
In Linux we don't have that culture. No tool (except perf) lives in the
ker
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann wrote:
> No support for booting from CDROM.
> No support for booting from Network.
> Thus no way to install a new guest image.
Sure. It's a pain point which we need to fix.
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann wrote:
> Booting an existing
Hi,
> "Usable" - I've tried kvm-tool several times and still (today) fail to
> get a standard SUSE image (with a kernel I have to compile and provide
> separately...) up and running *). Likely a user mistake, but none that
> is very obvious. At least to me.
Same here.
No support for booting fr
On 11/07/2011 09:45 AM, Pekka Enberg wrote:
>>> Specifications matter much more than working code. Quirks are a fact
>>> of life but should always come second.
>>
>> To quote Linus:
>>
>> And I have seen _lots_ of total crap work that was based on specs. It's
>> _the_ single worst way to write s
On 11/07/2011 09:45 AM, Pekka Enberg wrote:
Specifications matter much more than working code. Quirks are a fact
of life but should always come second.
To quote Linus:
And I have seen _lots_ of total crap work that was based on specs. It's
_the_ single worst way to write software, becaus
On 11/07/2011 09:09 AM, Pekka Enberg wrote:
We are obviously also using specifications but as you damn well should
know, specifications don't matter nearly as much as working code.
On Mon, 7 Nov 2011, Paolo Bonzini wrote:
Specifications matter much more than working code. Quirks are a fact of
On 11/07/2011 09:09 AM, Pekka Enberg wrote:
We are obviously also using specifications but as you damn well should
know, specifications don't matter nearly as much as working code.
Specifications matter much more than working code. Quirks are a fact of
life but should always come second.
To
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini wrote:
> (BTW, I'm also convinced like Ted that not having a defined perf ABI might
> have made sense in the beginning, but it has now devolved into bad software
> engineering practice).
I'm not a perf maintainer so I don't know what the situation wi
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini wrote:
> No, having the source code in Linux kernel tree is perfectly useless for the
> exceptional case, and forces you to go through extra hoops to build only one
> component. Small hoops such as adding "-- tools/kvm" to "git bisect start"
> perhap
On 11/06/2011 09:17 PM, Pekka Enberg wrote:
> No. I want to try new tool/old kernel and old tool/new kernel (kernel can
> be either guest or host, depending on the nature of the bug), and then
> bisect just one. (*) And that's the exceptional case, and only KVM tool
> developers really shou
On Mon, Nov 7, 2011 at 12:08 AM, Frank Ch. Eigler wrote:
>> [...] We don't want to be different, we want to make the barrier of
>> entry low.
>
> When has the barrier of entry into the kernel ever been "low"
> for anyone not already working in the kernel?
What's your point? Working on the KVM to
Hi Anthony,
On Sun, 6 Nov 2011, Anthony Liguori wrote:
- Drop SDL/VNC. Make a proper Cairo GUI with a full blown GTK interface.
Don't rely on virt-manager for this. Not that I have anything against
virt-manager but there are many layers between you and the end GUI if you go
that route.
Fun
On Sun, 6 Nov 2011, Ted Ts'o wrote:
The only excuse I can see is a hope to make random changes to the
kernel and userspace tools without having to worry about compatibility
problems, which is an argument I've seen with perf (that you have to
use the same version of perf as the kernel version, whi
On 11/06/2011 12:09 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori wrote:
I'm quite happy with KVM tool and hope they continue working on it. My only
real wish is that they wouldn't copy QEMU so much and would try bolder
things that are fundamentally different from QEM
On Sun, Nov 06, 2011 at 08:58:20PM +0200, Pekka Enberg wrote:
> > Ted, I'm confused. Making backwards incompatible ABI changes has never
> > been on the table. Why are you bringing it up?
>
> And btw, KVM tool is not a random userspace project - it was designed
> to live in tools/kvm from the begi
$
From: f...@redhat.com (Frank Ch. Eigler)
Date: Sun, 06 Nov 2011 17:08:48 -0500
In-Reply-To:
(Pekka
Enberg's message of "Sun, 6 Nov 2011 20:05:45 +0200")
Message-ID:
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-asci
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini wrote:
> Nothing, but I'm just giving you *strong* hints that a submodule or a merged
> tool is the wrong solution, and the histories of kernel and tool should be
> kept separate.
And btw, I don't really understand what you're trying to accomplish
wi
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini wrote:
>> If you're bisecting breakage that can be in the guest kernel or the
>> KVM tool, you'd want to build both.
>
> No. I want to try new tool/old kernel and old tool/new kernel (kernel can
> be either guest or host, depending on the nature of t
On 11/06/2011 08:17 PM, Pekka Enberg wrote:
> But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of
> years, I want all the shining new features you added in this time; I don't
> want the old end-2011 code. Same if I'm bisecting kernels, I don't want to
> build KVM tool
On Sun, Nov 6, 2011 at 9:14 PM, Paolo Bonzini wrote:
> GStreamer (V4L), RTSAdmin (LIO target), sg3_utils, trousers all are out of
> tree, and nobody of their authors is even thinking of doing all this
> brouhaha to get merged into Linus's tree.
We'd be the first subsystem to use the download scri
On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini wrote:
>> I really don't see the point in doing that. We want to be part of
>> regular kernel history and release cycle.
>
> But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of
> years, I want all the shining new features you add
On 11/06/2011 07:05 PM, Pekka Enberg wrote:
I mean, seriously, git makes it so easy to have a separate tree that
> it almost doesn't make sense not to have one. You're constantly
> working in separate trees yourself because every one of your
> branches is separate. Keeping in sync with the ker
On 11/06/2011 06:28 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf wrote:
The difference here is that although I feel Alex's script is a
pointless project, I'm in no way opposed to merging it in the tree if
people use it and it solves their problem. Some people seem to b
On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg wrote:
>> So integrating kvm-tool into the kernel isn't going to work as a free
>> pass to make non-backwards compatible changes to the KVM user/kernel
>> interface. Given that, why bloat the kernel source tree size?
>
> Ted, I'm confused. Making backw
On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
>> I'm quite happy with KVM tool and hope they continue working on it.
>> My only real wish is that they wouldn't copy QEMU so much and would
>> try bolder things that are fundamentally different from QEMU.
On Sun, Nov 6, 2011 at 8:3
On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
> I'm quite happy with KVM tool and hope they continue working on it.
> My only real wish is that they wouldn't copy QEMU so much and would
> try bolder things that are fundamentally different from QEMU.
My big wish is that they don'
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori wrote:
> I'm quite happy with KVM tool and hope they continue working on it. My only
> real wish is that they wouldn't copy QEMU so much and would try bolder
> things that are fundamentally different from QEMU.
Hey, right now our only source of cra
On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf wrote:
>> That's pretty much what git submodule would do, isn't it?
>>
>> I really don't see the point in doing that. We want to be part of
>> regular kernel history and release cycle. We want people to be able to
>> see what's going on in our tree to
On Sun, 6 Nov 2011, Jan Kiszka wrote:
Doesn't help here (with a disk image).
Also, both dependencies make no sense to me as we boot from disk, not
from net, and the console is on ttyS0.
It's only VIRTIO_NET and the guest is not actually stuck, it just takes a
while to boot:
[1.866614] I
On 06.11.2011, at 09:28, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf wrote:
>>> The difference here is that although I feel Alex's script is a
>>> pointless project, I'm in no way opposed to merging it in the tree if
>>> people use it and it solves their problem. Some pe
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf wrote:
>> The difference here is that although I feel Alex's script is a
>> pointless project, I'm in no way opposed to merging it in the tree if
>> people use it and it solves their problem. Some people seem to be
>> violently opposed to merging the
On 2011-11-06 18:11, Pekka Enberg wrote:
> On Sun, 6 Nov 2011, Jan Kiszka wrote:
>>> Can you please share your kernel .config with me and I'll take a look
>>> at it. We now have a "make kvmconfig" makefile target for enabling all
>>> the necessary config options for guest kernels. I don't think any
On 06.11.2011, at 05:06, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
>> You say that kvm-tool's scope is broader than Alex's script, therefore
>> the latter is pointless.
>
> I'm saying that Alex's script is pointless because it's not attempting
> to fix the real iss
On Sun, 6 Nov 2011, Jan Kiszka wrote:
Can you please share your kernel .config with me and I'll take a look
at it. We now have a "make kvmconfig" makefile target for enabling all
the necessary config options for guest kernels. I don't think any of
us developers are using SUSE so it can surely be
On 11/06/2011 07:06 AM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
You say that kvm-tool's scope is broader than Alex's script, therefore
the latter is pointless.
I'm saying that Alex's script is pointless because it's not attempting
to fix the real issues. For exam
On 06.11.2011, at 05:11, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
>> Alex's script, though, is just a few dozen lines. kvm-tool is a 20K
>> patch - in fact 2X as large as kvm when it was first merged. And it's
>> main feature seems to be that "it is not qemu".
>
On 11/06/2011 10:50 AM, Avi Kivity wrote:
On 11/06/2011 06:35 PM, Pekka Enberg wrote:
The difference here is that although I feel Alex's script is a
pointless project, I'm in no way opposed to merging it in the tree if
people use it and it solves their problem. Some people seem to be
violently o
On 11/06/2011 06:35 PM, Pekka Enberg wrote:
> >> The difference here is that although I feel Alex's script is a
> >> pointless project, I'm in no way opposed to merging it in the tree if
> >> people use it and it solves their problem. Some people seem to be
> >> violently opposed to merging the KVM
On 2011-11-06 17:30, Pekka Enberg wrote:
> Hi Jan,
>
> On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka wrote:
>> "Usable" - I've tried kvm-tool several times and still (today) fail to
>> get a standard SUSE image (with a kernel I have to compile and provide
>> separately...) up and running *). Likely
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka wrote:
> In contrast, you can throw arbitrary Linux distros in various forms at
> QEMU, and it will catch and run them. For me, already this is more usable.
Yes, I completely agree that this is an unfortunate limitation in the
KVM tool. We definitely nee
Hi Avi,
On Sun, Nov 6, 2011 at 5:56 PM, Avi Kivity wrote:
> On 11/06/2011 03:06 PM, Pekka Enberg wrote:
>> On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
>> > You say that kvm-tool's scope is broader than Alex's script, therefore
>> > the latter is pointless.
>>
>> I'm saying that Alex's scri
Hi Jan,
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka wrote:
> "Usable" - I've tried kvm-tool several times and still (today) fail to
> get a standard SUSE image (with a kernel I have to compile and provide
> separately...) up and running *). Likely a user mistake, but none that
> is very obvious. A
On 2011-11-06 14:06, Pekka Enberg wrote:
> Sure. I think it's mostly people that are interested in non-Linux
> virtualization that think the KVM tool is a pointless project.
> However, some people (including myself) think the KVM tool is a more
> usable and hackable tool than QEMU for Linux virtual
On 11/06/2011 03:06 PM, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
> > You say that kvm-tool's scope is broader than Alex's script, therefore
> > the latter is pointless.
>
> I'm saying that Alex's script is pointless because it's not attempting
> to fix the real issue
On 2011-08-24 23:38, Alexander Graf wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built actually wor
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
> Alex's script, though, is just a few dozen lines. kvm-tool is a 20K
> patch - in fact 2X as large as kvm when it was first merged. And it's
> main feature seems to be that "it is not qemu".
I think I've mentioned many times that I find the QEM
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
> You say that kvm-tool's scope is broader than Alex's script, therefore
> the latter is pointless.
I'm saying that Alex's script is pointless because it's not attempting
to fix the real issues. For example, we're trying to make make it as
easy as
On 11/06/2011 02:32 PM, Pekka Enberg wrote:
> On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity wrote:
> > But from your description, you're trying to solve just another narrow
> > problem:
> >
> > "The end game for me is to replace QEMU/VirtualBox for Linux on Linux
> > virtualization for my day to day
On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity wrote:
> But from your description, you're trying to solve just another narrow
> problem:
>
> "The end game for me is to replace QEMU/VirtualBox for Linux on Linux
> virtualization for my day to day purposes. "
>
> We rarely merge a subsystem to solve one
1 - 100 of 126 matches
Mail list logo
