On 25.07.2011, at 10:54, Ingo Molnar wrote: > > * Alexander Graf <agraf@xxxxxxx> wrote: > >> On 25.07.2011, at 09:53, Ingo Molnar wrote: >> >>> >>> * Pekka Enberg <penberg@xxxxxxxxxx> wrote: >>> >>>> On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka <jan.kiszka@xxxxxx> wrote: >>>>> >>>>> That said, I definitely appreciate the bug fixes as well as >>>>> code and documentation improvements for KVM that originate from >>>>> this effort! I'm just not convinced that writing a new userland >>>>> and merging it into the kernel is the most efficient way to >>>>> achieve that. >>>> >>>> Just to make this crystal clear for everyone: if it weren't for >>>> tools/kvm, I wouldn't be hacking on KVM at all. I've looked at >>>> Qemu in the past (and a lot recently!) and I simply don't see >>>> myself contributing to it, sorry. So 'most efficient' or not, I >>>> think tools/kvm is a net win for Linux and KVM in general. >>> >>> Same here - in fact i first asked Qemu to be put into tools/qemu/ >>> so that it all becomes more hackable and more usable - that >>> suggestion was rebuked very strongly. >> >> So instead of thinking a bit and trying to realize that there might >> be a reason people don't want all their user space in the kernel >> tree you go ahead and start your own crusade of creating a new user >> space. Great. That's how I always hoped Linux would be :(. > > Not "all their user space" but the ones that are tightly integrated > with the kernel to begin with. How hard is that concept to > understand? It's very hard to understand. It's similar to religion - I could easily apply your point to every reasonably low-level user space project out there. X for example. X needs to interact with KMS and DRI and whatdoiknow. So it'd be a perfect fit to pull into tools/, no? > Virtualization is very tightly bound to the kernel, like it or not. I don't see why. The whole point of virtualization is to model simple, with KVM preferably even very-close-to-real-hardware interfaces that allow you to keep things separate. > So is profiling, power management and a few other things. I'm also failing to see the reasoning here TBH. > And when you do 'ls tools/' you'll see exactly those topics > populated: > > earth5:~/tip> ls tools/ > firewire kvm perf power slub testing usb virtio > > [ In fact tools/virtio/ was merged upstream yesterday and putting > that code there was a good call IMO. ] > > So just as there are good reasons to keep some user-space projects > out of the kernel tree (while i'd love to see a usable mail client > for Linux i dont think it belongs into tools/) there are similarly > good reasons to keep some of them in the kernel tree. > > tools/kvm/ is an excellent example for that, just look at the code - > it shares code with the kernel, uses the kernel coding style, is in > significant part developed by kernel developers and it is being used > by kernel developers. Then make a separate tree, add the kernel as git submodule and simply pull in your library/header dependencies from there. Shouldn't be too hard, no? > I wish there was a hackable tools/qemu/ base but there isnt and won't > be any. The thing i *can* do is to help create a hackable > virtualization tool. What's the problem with a code base that's hackable, but not in tools/? > >>> So i wanted to have a lightweight tool that allows me to test KVM >>> and tools/kvm/ does that very nicely: i type './kvm run' and i >>> can test a native bzImage (which has some virtualization options >>> enabled as well) on the _host_ distro i am running, booting to a >>> text shell prompt. >> >> I do that all the time. >> >> $ qemu-kvm -nographic -kernel arch/x86/boot/bzImage -append console=ttyS0 >> >> does the exact same thing. If that's too much typing for you, make >> it a bash alias. > > This only boots the bzImage itself and panics when it would like to > hit user-space. Well, sure. > >>> I can do that without downloading any (inevitably outdated) >>> virtualization images or maintaining my own ones. Maintaining >>> host userspace is more than enough for me. >> >> Who would need images? I usually only run -kernel and -initrd >> directly to test out things. Or if I really want to boot into a >> real system I do -snapshot /dev/sda. > > that too panics here, while with tools/kvm/ i get to a prompt: > > [root@aldebaran ~]# uptime > 08:42:13 up 0 min, 0 users, load average: 0.00, 0.00, 0.00 > > But i agree with you that obviously Qemu (or my usage of parameters, > whichever is the problem) could be fixed to do this correctly. Well, you need to make sure to pass the right partition into -append. No idea what ./kvm run does, but it's certainly something easily scriptable with any other virtualization user land. > >>> So, since we already have the lguest tool in the kernel tree, why >>> cannot we have the much more capable tools/kvm/ in the tree? >> >> Lguest is in Documentation/ for a reason. It's not meant as a user >> space tool that you take as-is and use. It's meant for documenting >> how lguest works in general. I admit though, that that's also the >> reason people don't use it :). > > There's an obvious contrast with the request to merge tools/kvm/ to > lguest (not brought up by me) and your description of lguest only > being for documentation purposes, not to be used really, etc. > > I wanted to highlight this contrast, so if you thought we disagree > much about lguest i don't think we do. I don't think we disagree about lguest :). > >>> So while it is the Qemu folks' right to oppose tools/qemu/, i >>> don't see why they are opposing tools/kvm/ ... >> >> In your logic, you would put all of the GNU utils into tools/. This >> is just plain insane. There's a reason we have the split between >> kernel and user space. What does putting them into the same tree >> bring you? Fame? Glorious stats on kernel commits? Seriously, it's >> a separate project. It's not the kernel. > > Where did i claim that *all* user-space projects need to move into > the kernel tree? It's all case by case. Before you argue against a > position and ridicule it you need to understand it. I'm slightly exaggerating, but that's the trend I'm seeing. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
