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 and
see
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 simple tool he
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!
* Vince Weaver vi...@deater.net 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
Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
* Vince Weaver vi...@deater.net 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
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 ty...@mit.edu 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
On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak k...@redhat.com 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
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. Even
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@infradead.org 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
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
This will
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 will drop you into
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@infradead.org 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.
On Tue, Nov 08, 2011 at 05:26:03PM +0200, Pekka Enberg wrote:
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@infradead.org 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
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 any
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.
Doesn't work
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
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 the kernel
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 vi...@deater.net wrote:
as mentioned before I have my own perf_event test suite with 20+ tests.
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 should
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@redhat.com 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
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@redhat.com 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
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.
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: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,
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,
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 from
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann kra...@redhat.com 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
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
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 different
On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann kra...@redhat.com 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.
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 just
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 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
On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini pbonz...@redhat.com 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
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
making it
* Pekka Enberg penb...@cs.helsinki.fi 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
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 against) it.
On 11/07/11 12:44, Pekka Enberg wrote:
On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini pbonz...@redhat.com 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
On Mon, Nov 7, 2011 at 2:18 PM, Gerd Hoffmann kra...@redhat.com 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.
On 11/07/2011 12:30 PM, Sasha Levin wrote:
On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann kra...@redhat.com 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.
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 advantages
Hi Avi,
On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity a...@redhat.com 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
Hi Ted,
On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o ty...@mit.edu 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
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,
On 11/07/2011 02:29 PM, Pekka Enberg wrote:
Hi Avi,
On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity a...@redhat.com 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
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 ty...@mit.edu 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
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu 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
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu 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
On 11/07/2011 05:57 AM, Ingo Molnar wrote:
* Pekka Enbergpenb...@cs.helsinki.fi 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.
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 Swirl; Avi
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
* Vince Weaver vi...@deater.net 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.
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 vi...@deater.net wrote:
Never overtly. They're too clever for that.
If you want me to take you seriously, spare me from the conspiracy
Ingo Molnar mi...@elte.hu 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
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
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 hard
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 test
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o ty...@mit.edu 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
On 11/07/2011 03:36 PM, Pekka Enberg wrote:
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'oty...@mit.edu 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
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
and
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 breakages,
Hi Alexander,
On Sun, Nov 6, 2011 at 3:35 AM, Alexander Graf ag...@suse.de 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
On 11/06/2011 12:04 PM, Pekka Enberg wrote:
Hi Alexander,
On Sun, Nov 6, 2011 at 3:35 AM, Alexander Graf ag...@suse.de 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
On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity a...@redhat.com wrote:
I'm happy to see some real competition for the KVM tool in usability. ;-)
That said, while the script looks really useful for developers,
wouldn't it make more sense to put it in QEMU to make sure it's kept
up-to-date and
On 11/06/2011 12:12 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity a...@redhat.com wrote:
I'm happy to see some real competition for the KVM tool in usability. ;-)
That said, while the script looks really useful for developers,
wouldn't it make more sense to put it in
Hi Avi,
On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
If this is a serious attempt in making QEMU command line suck less on
Linux, I think it makes sense to do this properly instead of adding a
niche script to the kernel tree that's simply going to bit rot over
time.
You
On 11/06/2011 01:08 PM, Pekka Enberg wrote:
On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
In most installations, qemu is driven by other programs, so any changes
to the command line would be invisible, except insofar as they break things.
For the occasional direct user of qemu,
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com wrote:
People seem to think the KVM tool is only about solving a specific
problem to kernel developers. That's certainly never been my goal as I
do lots of userspace programming as well. The end game for me is to
replace
On 11/06/2011 02:14 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com wrote:
People seem to think the KVM tool is only about solving a specific
problem to kernel developers. That's certainly never been my goal as I
do lots of userspace programming as well.
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com wrote:
So far, kvm-tool capabilities are a subset of qemu's. Does it add
anything beyond a different command-line?
I think different command line is a big thing which is why we've
spent so much time on it. But if you mean other end
On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity a...@redhat.com 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
On 11/06/2011 02:32 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity a...@redhat.com 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
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com 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
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com 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
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 works.
On 11/06/2011 03:06 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com 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
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
Hi Jan,
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de 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
Hi Avi,
On Sun, Nov 6, 2011 at 5:56 PM, Avi Kivity a...@redhat.com wrote:
On 11/06/2011 03:06 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
You say that kvm-tool's scope is broader than Alex's script, therefore
the latter is pointless.
I'm
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de 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.
On 2011-11-06 17:30, Pekka Enberg wrote:
Hi Jan,
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de 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 *).
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 tool and
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
On 06.11.2011, at 05:11, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com 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
On 11/06/2011 07:06 AM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivitya...@redhat.com 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
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 a
On 06.11.2011, at 05:06, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com 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
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 of
us
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf ag...@suse.de 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
On 06.11.2011, at 09:28, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf ag...@suse.de 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.
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]
On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf ag...@suse.de 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
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori anth...@codemonkey.ws 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
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't
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:31 PM,
On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg penb...@kernel.org 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.
On 11/06/2011 06:28 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Grafag...@suse.de 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
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
On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini pbonz...@redhat.com 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
On Sun, Nov 6, 2011 at 9:14 PM, Paolo Bonzini pbonz...@redhat.com 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
1 - 100 of 126 matches
Mail list logo
