Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 merges (where tip:master was == tip:next) to the older complete reintegration merges to linux-next every couple of weeks. This way tools/kvm will still be available in tip:master (merged after full integrations) and there are still the usual daily (or more frequent) delta-merges of tip:master as new bits get ready - with the occasional riskier total reintegration done for linux-next. It's obviously not optimal, but that's the best I could come up with given the constraints. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 the daily merges (where tip:master was == tip:next) to the older complete reintegration merges to linux-next every couple of weeks. This way tools/kvm will still be available in tip:master (merged after full integrations) and there are still the usual daily (or more frequent) delta-merges of tip:master as new bits get ready - with the occasional riskier total reintegration done for linux-next. It's obviously not optimal, but that's the best I could come up with given the constraints. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 out-of-tree patches had existed for QEMU for more than a year. It was developed with QEMU. I think Ingo confused virtio and vhost. IIRC, Asias developed vhost-blk using tools/kvm. We've done extensive performance analysis of vhost-blk and it's not any faster than a userspace solution. This is why it's still not in mainline. This wasn't noticed with tools/kvm because it's block layer is too simplistic. In order to get to the point where we're able to do this well in userspace in QEMU took tons of bug fixes to the kernel and added features (like pread64/pwrite64). That all happened without QEMU being in the kernel. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 tools/kvm, but out-of-tree patches had existed for QEMU for more than a year. It was developed with QEMU. I think Ingo confused virtio and vhost. IIRC, Asias developed vhost-blk using tools/kvm. We've done extensive performance analysis of vhost-blk and it's not any faster than a userspace solution. This is why it's still not in mainline. This wasn't noticed with tools/kvm because it's block layer is too simplistic. In order to get to the point where we're able to do this well in userspace in QEMU took tons of bug fixes to the kernel and added features (like pread64/pwrite64). That all happened without QEMU being in the kernel. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 QEMU for more than a year. It was developed with QEMU. I think Ingo confused virtio and vhost. IIRC, Asias developed vhost-blk using tools/kvm. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 listed ARM KVM support which was written/prototyped
>using tools/kvm.
Again, I think both QEMU and tools/kvm were used, with QEMU probably
coming first. However, I'm not 100% sure.
> - There's over a dozen bugfixes in your kernel which were found
>via syscall fuzzing built into tools/kvm. (I can dig them all
>out if you want.)
This sounds like something that runs in a guest, not in the host. As
such it need not be tied to tools/kvm. If there is a host component
(host C code), I'd be interested. I know that Fujitsu guys have patches
for panic notification from the guest kernel, for example.
But if there is a host component to it, then please go back to the
original purpose of tools/kvm. Drop all the QCOW, VNC, SeaBIOS
nonsense. Drop the userspace networking stack (tap is enough). Make
the tool into a library that supports nothing but virtio-{blk,net,9p}
and VFIO. Build _many_ narrow-focused tools around that library.
>> "sparse" is useful for kernel development. "git" is useful for
>> kernel development. "xterm" is useful for kernel development.
>
> That argument is silly beyond belief. Read this list:
>
> - tools/kvm
> - sparse
> - git
> - xterm
> - perf
>
> Which two tools in this list:
>
> - Use and focus on Linux specific system calls to provide Linux
>specific functionality?
>
> - Are never - and will conceivably never - run on any kernel
>which is not extremely Linux compatible?
QEMU runs KVM on Solaris, FWIW.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 listed ARM KVM support which was written/prototyped
using tools/kvm.
Again, I think both QEMU and tools/kvm were used, with QEMU probably
coming first. However, I'm not 100% sure.
- There's over a dozen bugfixes in your kernel which were found
via syscall fuzzing built into tools/kvm. (I can dig them all
out if you want.)
This sounds like something that runs in a guest, not in the host. As
such it need not be tied to tools/kvm. If there is a host component
(host C code), I'd be interested. I know that Fujitsu guys have patches
for panic notification from the guest kernel, for example.
But if there is a host component to it, then please go back to the
original purpose of tools/kvm. Drop all the QCOW, VNC, SeaBIOS
nonsense. Drop the userspace networking stack (tap is enough). Make
the tool into a library that supports nothing but virtio-{blk,net,9p}
and VFIO. Build _many_ narrow-focused tools around that library.
sparse is useful for kernel development. git is useful for
kernel development. xterm is useful for kernel development.
That argument is silly beyond belief. Read this list:
- tools/kvm
- sparse
- git
- xterm
- perf
Which two tools in this list:
- Use and focus on Linux specific system calls to provide Linux
specific functionality?
- Are never - and will conceivably never - run on any kernel
which is not extremely Linux compatible?
QEMU runs KVM on Solaris, FWIW.
Paolo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 existed for QEMU for more than a year. It was developed with QEMU. I think Ingo confused virtio and vhost. IIRC, Asias developed vhost-blk using tools/kvm. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 help both projects. The kernel wants to keep > > the 'tit' only though. > > Ingo, stop this idiotic nonsense. > > You seem to think that "kvmtool is useful for kernel" is > somehow relevant. > > IT IS TOTALLY IRRELEVANT. Please stop misrepresenting my opinion. My argument continues to be that it was useful to the kernel in significant part *BECAUSE* tools/kvm/ was integrated into a kernel repository - on the main developers' systems. You seem to take it for granted that causality cannot possibly go the way that these kernel enhancements came mainly because the tool was integrated into a kernel repo and was developed very consciously within a kernel repo, as a (foster-)sister project. Why are you making that assumption? It's totally debatable and we, who experienced that development process first hand, are fiercely debating it. Check the list I gave (unmodified): "- Pekka listed new virtio drivers that were done via tools/kvm. - Pekka listed ARM KVM support which was written/prototyped using tools/kvm. - There's over a dozen bugfixes in your kernel which were found via syscall fuzzing built into tools/kvm. (I can dig them all out if you want.) - There are several fixes in the kernel side KVM subsystem itself that were unearthed via tools/kvm. - I showed how it helped the kernel by creating user-space lockdep: code used in more situations means more exposure, more bugfixes and more contributors. (It also allowed immediate lockdep coverage for all the user-space mutexes that tools/perf/ itself uses.)" All but the fourth item (KVM fixes) were benefits that arose largely because the tool was integrated into a kernel repository and the developers found it easy to work that way. In at least 3 cases above I could describe the actual, specific development process that involved a single code base, even adding features to *BOTH* the tool and the kernel, in one work flow. The resulting patches were then rebased after the fact (mostly by Pekka), to merge upstream separately while waiting for the tool to prove itself for upstream - losing its origin, motivation and its history. Could it have been attempted separately? Yes, just like perf could have been tried as a separate project - but that is not how it happened, that is not how the development flow unfolded, and that is not what motivated those enhancements. Just because it _could_ have been done independently does not change the plain fact that tools/kvm was immensely kernel focused. Yes, it was unsolicited, yes you objected early on and loud enough, and the kernel did not ask for this integration to begin with - so there's not a hint of obligation on your part whatsoever, but that does not change development reality as it happened. I refuse to accept the rewriting of history. > "sparse" is useful for kernel development. "git" is useful for > kernel development. "xterm" is useful for kernel development. That argument is silly beyond belief. Read this list: - tools/kvm - sparse - git - xterm - perf Which two tools in this list: - Use and focus on Linux specific system calls to provide Linux specific functionality? - Are never - and will conceivably never - run on any kernel which is not extremely Linux compatible? - Provide essential features that need serious, tool specific kernel side support? - Were used directly to create integrated features that add features BOTH to the kernel and the tool, at once? I know that this discussion is not about changing your mind anymore - every further email probably does the opposite. I would accept many other arguments from you: - you feel uneasy about growing the kernel into any sort of platform. I would disagree but it's a fair argument. - you think kernel developers should not do user-space development and there should be a 'chinese wall' of ignorance and a project boundary or two between them. I would disagree but it's a fair argument. - you think Qemu is better and is the official kernel side KVM tool, and even if it's not better, it's (much) more complete and a schizm is bad. It's a fair argument that I'd somewhat agree with. - you feel that if a tool cannot survive in the harsh realities of the sourceforge or github ghetto, succeeding in establishing itself and then hurting generations of users with inconsistent, uncoordinated tinkerware, no matter how Linux kernel centric the tool is conceptually, then it does not deserve to live at all. I would disagree but it would be a fair argument. - you feel the kernel should be fundamentally tool neutral, even if the
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 upstream kernel which would further help both projects. The kernel wants to keep the 'tit' only though. Ingo, stop this idiotic nonsense. You seem to think that kvmtool is useful for kernel is somehow relevant. IT IS TOTALLY IRRELEVANT. Please stop misrepresenting my opinion. My argument continues to be that it was useful to the kernel in significant part *BECAUSE* tools/kvm/ was integrated into a kernel repository - on the main developers' systems. You seem to take it for granted that causality cannot possibly go the way that these kernel enhancements came mainly because the tool was integrated into a kernel repo and was developed very consciously within a kernel repo, as a (foster-)sister project. Why are you making that assumption? It's totally debatable and we, who experienced that development process first hand, are fiercely debating it. Check the list I gave (unmodified): - Pekka listed new virtio drivers that were done via tools/kvm. - Pekka listed ARM KVM support which was written/prototyped using tools/kvm. - There's over a dozen bugfixes in your kernel which were found via syscall fuzzing built into tools/kvm. (I can dig them all out if you want.) - There are several fixes in the kernel side KVM subsystem itself that were unearthed via tools/kvm. - I showed how it helped the kernel by creating user-space lockdep: code used in more situations means more exposure, more bugfixes and more contributors. (It also allowed immediate lockdep coverage for all the user-space mutexes that tools/perf/ itself uses.) All but the fourth item (KVM fixes) were benefits that arose largely because the tool was integrated into a kernel repository and the developers found it easy to work that way. In at least 3 cases above I could describe the actual, specific development process that involved a single code base, even adding features to *BOTH* the tool and the kernel, in one work flow. The resulting patches were then rebased after the fact (mostly by Pekka), to merge upstream separately while waiting for the tool to prove itself for upstream - losing its origin, motivation and its history. Could it have been attempted separately? Yes, just like perf could have been tried as a separate project - but that is not how it happened, that is not how the development flow unfolded, and that is not what motivated those enhancements. Just because it _could_ have been done independently does not change the plain fact that tools/kvm was immensely kernel focused. Yes, it was unsolicited, yes you objected early on and loud enough, and the kernel did not ask for this integration to begin with - so there's not a hint of obligation on your part whatsoever, but that does not change development reality as it happened. I refuse to accept the rewriting of history. sparse is useful for kernel development. git is useful for kernel development. xterm is useful for kernel development. That argument is silly beyond belief. Read this list: - tools/kvm - sparse - git - xterm - perf Which two tools in this list: - Use and focus on Linux specific system calls to provide Linux specific functionality? - Are never - and will conceivably never - run on any kernel which is not extremely Linux compatible? - Provide essential features that need serious, tool specific kernel side support? - Were used directly to create integrated features that add features BOTH to the kernel and the tool, at once? I know that this discussion is not about changing your mind anymore - every further email probably does the opposite. I would accept many other arguments from you: - you feel uneasy about growing the kernel into any sort of platform. I would disagree but it's a fair argument. - you think kernel developers should not do user-space development and there should be a 'chinese wall' of ignorance and a project boundary or two between them. I would disagree but it's a fair argument. - you think Qemu is better and is the official kernel side KVM tool, and even if it's not better, it's (much) more complete and a schizm is bad. It's a fair argument that I'd somewhat agree with. - you feel that if a tool cannot survive in the harsh realities of the sourceforge or github ghetto, succeeding in establishing itself and then hurting generations of users with inconsistent, uncoordinated tinkerware, no matter how Linux kernel centric the tool is conceptually, then it does not deserve to live at all. I would disagree but it would be a fair argument. - you feel the kernel should be fundamentally tool neutral,
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 keep the 'tit' > only though. Ingo, stop this idiotic nonsense. You seem to think that "kvmtool is useful for kernel" is somehow relevant. IT IS TOTALLY IRRELEVANT. "sparse" is useful for kernel development. "git" is useful for kernel development. "xterm" is useful for kernel development. See a pattern? We have tons of tools that are helping develop the kernel, and for absolutely NONE of them is that at all an argument for merging them into the kernel. If the Xen people came and asked me to merge their virtualizer code into the kernel, I'd call them idiots. Why is kvmtool so magical that you use this argument for merging it into the kernel? It makes no sense. Yet you continue to use it as if it was somehow an argument for merging it. Despite the hundreds of projects to the contrary. So this whole "constant stream of benefits" you talk about is PURE AND UTTER GARBAGE. And that's not a commentary on whether it is true or not, it's a commentary on the fact that it is entirely irrelevant to whether something should be merged. Merging two projects does not make them easier to maintain. Quite the reverse. It just ties the maintenance together in irrelevant ways. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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? Everything you > claim is such a big deal would still work perfectly well. > > Every time you talk about "negative" it's as of the project > wouldn't exist if it was external. Which is total bull, since > it is effectively external already. [...] That's not actually true. If you check the list of early tools/kvm/ contributors you will see an overlap with -tip contributors. I know tools/kvm/ developers who just use their existing -tip repo to pick up the latest. They are using the -tip commit notifications to see what went in and what not, etc. Claiming that because the contribution model works to a certain degree integrated into a small Linux subsystem tree it does not ever have to go upstream is so wrong on so many levels ... The most likely correct statement would be something like: "if it worked on a small scale it will probably work even better with more exposure on a larger scale." We'll never know that though. ( That is also why some of the focus was on lockdep - knowing that it's close in terms of maintenance distance made it an easier topic - socially. ) Since I'm using it on an almost daily basis to test out failed bzImages, and because I (mistakenly) thought it had some upstream chances, I found it good to help out (a bit) with maintenance and code review. While it works it's obviously limited - there's just so many -tip developers and I thought everyone would benefit from this going the next natural step. > [...] And it will stay that way. You are just in denial and > trying to say that integrating it would somehow help. > > And I claim it wouldn't. It works fine outside already. Just > ADMIT it. So tools/kvm/ works 'just fine' - in its current limited form - because for the developers involved it's already "upstream", for the first hop of upstream. 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 keep the 'tit' only though. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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, trust, distribution, standards, enforcement > > agencies and available workers. > > > > Could the same business succeed in Somalia as well? Possibly - > > if it's a bakery or something similarly fundamental. More > > complex businesses would likely not thrive very well there. > > > > *That* is how I think the current Linux kernel tooling landscape > > looks like currently in a fair number of places: in many aspects > > it's similar to Somalia - disjunct entities with not much > > commonality or shared infrastructure. > > That's complete nonsense. If you want to use pieces of the > kernel infrastructure, then just *take* them. [...] So I can take the mailing lists and the whole contribution culture? Hardly... I was not talking about code alone, I was also talking about a social environment - which is not a one sided relationship at all, it improves the kernel code, like it already did for over two dozen tools/kvm originated patches: To quote from my mail to Linus: " - Pekka listed new virtio drivers that were done via tools/kvm. - Pekka listed ARM KVM support which was written/prototyped using tools/kvm. - There's over a dozen bugfixes in your kernel which were found via syscall fuzzing built into tools/kvm. (I can dig them all out if you want.) - There are several fixes in the kernel side KVM subsystem itself that were unearthed via tools/kvm. - I showed how it helped the kernel by creating user-space lockdep: code used in more situations means more exposure, more bugfixes and more contributors. (It also allowed immediate lockdep coverage for all the user-space mutexes that tools/perf/ itself uses.) Those were all real benefits to the kernel which are upstream or almost upstream today. This tool alone generated a *more* versatile number of improvements to the kernel than the majority of filesystems and the majority of drivers in the Linux kernel tree today has ever achieved. " > [...] There are loads of projects which use the kernel config > tools, for example. There's no need to be *in* the kernel > repo. > > And for code-reuse it's even easy enough to automatically > extract parts of kernel code into a separate repository. [...] ... which solution would: - lose all history - lose contributor awareness of each other - lose easy cross-contribution pathways That's a severe net minus in my opinion. I think you should try to answer the very fundamental observation I made and the question I asked in my mail to Tytso: " We have first hand experience there: tools/perf/. None of the predicted extreme badness happened. Yes, sometimes we broke compatibility as ABI changes/enhancements do - but treated them as regressions and fixed them. I also think that considering the rate of changes our breakage ratio is very good. So no badness happened, and in fact a lot of goodness happened: which goodness never happened while Linux profiling was a separate project isolated as a user-space utility! Anyone opposing integration I think *HAS* to explain the mechanics behind this very example in plain sight. Why the heck has pretty much every other out of tree profiling project died, while the in-tree one is thriving? Yes, the key is that Arnaldo is good, and so are the other perf contributors - and they are good because they feel at home and they are productive. Being in the kernel repo is actually 90% responsible for that environment! " And yes, based on the evidence I think much of perf's current vitality would be killed off or would be severely reduced if it was forced into a separate, out of tree project. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 need to be *in* the kernel repo. Exactly. I do *not* want a abstraction layer just because somebody wants to use it. It causes idiotic guards in the header files etc. We already had that pain with the user-level header inclusions etc. Just copy it. The UAPI work and "make headers_install" already has cleaned things up immensely. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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. > > You go on to explain how this helps kvmtool, and quite > frankly, I DO NOT CARE. Me and Pekka also listed several examples of how it already helped the kernel, despite it only being partially present in some kernel repos: - Pekka listed new virtio drivers that were done via tools/kvm. - Pekka listed ARM KVM support which was written/prototyped using tools/kvm. - There's over a dozen bugfixes in your kernel which were found via syscall fuzzing built into tools/kvm. (I can dig them all out if you want.) - There are several fixes in the kernel side KVM subsystem itself that were unearthed via tools/kvm. - I showed how it helped the kernel by creating user-space lockdep: code used in more situations means more exposure, more bugfixes and more contributors. (It also allowed immediate lockdep coverage for all the user-space mutexes that tools/perf/ itself uses.) Those were all real benefits to the kernel which are upstream or almost upstream today. This tool alone generated a *more* versatile number of improvements to the kernel than the majority of filesystems and the majority of drivers in the Linux kernel tree today has ever achieved. How on earth can anyone, against all that evidence, still claim that it's a net minus? > Everything you talk about is about helping your work, by > making the kernel maintenance be more. The fact that you want > to use kernel infrastructure in kvmtool is a great example: > you may think it's a great thing, but for the kernel it's just > extra work, and extra layers of abstraction etc etc. At least in the case of lockdep, the kernel side change enabling it was a trivial: kernel/lockdep.c | 4 1 file changed, 4 insertions(+) ... but we could probably make even that interaction go away and make it exactly zero, and push all the changes on to the liblockdep side. Anyway, should I consider user space lockdep NAK-ed too in this form, before we put any more work into it? > And then you make it clear that you haven't even *bothered* to > try to make it a separate project. Just like back in the days you haven't even bothered to make Linux a proper GNU project, and for good reasons. Nor have I ever tried to write scheduler code for another OS. Some expensive, disruptive things you don't "try" because you disagree with the model, on what you think to be valid grounds. You make a judgement call, you take your chances, and you see whether it works. > Sorry, but with that kind of approach, I get less and less > interested. I think this whole tying together is a big > mistake. It encourages linkages that simply shouldn't be > there. > > And no, perf is not the perfect counter-example. With perf,. > the linkages made sense! There's supposed to be deep linkages > to profiling and event counting. There is ABSOLUTELY NOT > supposed to be deep linkages with virtualization. Quite the > reverse. I'm *really* surprised that you say that. perf interfaces to the Linux kernel in a very similar way to how tools/kvm interfaces to the Linux kernel: both use (very) Linux specific system calls to run on a host system running the Linux kernel. Neither tool will in the foreseeable future execute on any other, non-Linux host kernel. ( Running non-Linux guest OS's is an entirely different matter and there's no fundamental restriction there. ) tools/perf/ is not in the kernel because it interfaces with the kernel in nasty, incestous ways. It is in the kernel mainly because that's the contribution model that turned out to work well for both the kernel and the tooling side: I initially made the user-space bits of perf a separate project. I didn't run it in that form for a long time, but I got essentially zero contributions. The moment it went into a silly directory in Documentation/perf_counters/, contributions started trickling in. Today it's fully embraced by the kernel side subsystem and allows very efficient interface enhancements on the kernel and tooling side, in lock-step - benefiting both sides significantly. > And no, I don't want to maintain the mess that is both. > There's just no gain, and lots of potential pain. I disagree, and I don't see the validity of most of your arguments, but it's obviously your call. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 >> > 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. > > > > You're probably better off focusing on OVMF rather than just SeaBIOS. > > SeaBIOS has CSM support now, so it can provide 'legacy' BIOS services > under OVMF. So if OVMF runs, you get both EFI and legacy support. > > -- > dwmw2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 yeah, we'll hopefully support non-Linux guest at > some point. You're probably better off focusing on OVMF rather than just SeaBIOS. SeaBIOS has CSM support now, so it can provide 'legacy' BIOS services under OVMF. So if OVMF runs, you get both EFI and legacy support. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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. Exactly. I do *not* want a abstraction layer just because somebody wants to use it. It causes idiotic guards in the header files etc. We already had that pain with the user-level header inclusions etc. Just copy it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 quite frankly, I DO NOT CARE. Everything you talk about is about helping your work, by making the kernel maintenance be more. The fact that you want to use kernel infrastructure in kvmtool is a great example: you may think it's a great thing, but for the kernel it's just extra work, and extra layers of abstraction etc etc. And then you make it clear that you haven't even *bothered* to try to make it a separate project. Sorry, but with that kind of approach, I get less and less interested. I think this whole tying together is a big mistake. It encourages linkages that simply shouldn't be there. And no, perf is not the perfect counter-example. With perf,. the linkages made sense! There's supposed to be deep linkages to profiling and event counting. There is ABSOLUTELY NOT supposed to be deep linkages with virtualization. Quite the reverse. And no, I don't want to maintain the mess that is both. There's just no gain, and lots of potential pain. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar wrote: >> What if somebody tells you that they are really tired of Xen, >> and actually want to turn kvmtool into *replacement* for Xen >> instead? [...] > > Actually, this was raised by some people - and I think some > generalization patches were applied already but Pekka might know > more about that ... There was some interest but I don't think anybody sent patches for that. There's no fundamental reason why we couldn't support Xen if people are interested in working on that. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
[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 for x86. Now if you look at this: https://github.com/penberg/linux-kvm/commit/051bdb63879385e12b7e253b72cdde909a5e0b9b There are other platforms added. Look here: https://wiki.linaro.org/LEG/Engineering/Virtualization [quote]kvmtool is used meanwhile[/quote] They are using it ! On Mon, Feb 11, 2013 at 3:18 PM, 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, trust, distribution, standards, enforcement >> agencies and available workers. >> >> Could the same business succeed in Somalia as well? Possibly - >> if it's a bakery or something similarly fundamental. More >> complex businesses would likely not thrive very well there. >> >> *That* is how I think the current Linux kernel tooling landscape >> looks like currently in a fair number of places: in many aspects >> it's similar to Somalia - disjunct entities with not much >> commonality or shared infrastructure. > > 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. > > And for code-reuse it's even easy enough to automatically extract parts > of kernel code into a separate repository. See the ecos-jffs2 and > linux-headers trees, for example, which automatically tracked Linus' > tree with a certain transformation to make them sane for just pulling > into the relevant target repositories. > > -- > dwmw2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 > agencies and available workers. > > Could the same business succeed in Somalia as well? Possibly - > if it's a bakery or something similarly fundamental. More > complex businesses would likely not thrive very well there. > > *That* is how I think the current Linux kernel tooling landscape > looks like currently in a fair number of places: in many aspects > it's similar to Somalia - disjunct entities with not much > commonality or shared infrastructure. 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. And for code-reuse it's even easy enough to automatically extract parts of kernel code into a separate repository. See the ecos-jffs2 and linux-headers trees, for example, which automatically tracked Linus' tree with a certain transformation to make them sane for just pulling into the relevant target repositories. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 >modifications to kernel/lockdep.c enabled it to be >librarified, and then the remaining work was done in >user-space - here too in successive steps. > > - tools/kvm/ happened to be hosted in the same kernel repo >that the locking tree is hosted in. > > The end result is something good that I never saw happen to > kernel code before, in the last 20 years of the Linux kernel. > Maybe it could have happened with an outside tools/kvm repo, > but I very strongly suspect that it would not. > > In theory this could have been done in the cold, fragmented, > isolated and desolate landscape of Linux user-space utilities, > by copying kernel/lockdep.c and a handful of kernel headers to > user-space, and making it work there somehow. > > Just like a blue rose could in theory grow on Antarctica as > well, given the right set of circumstances. It just so happens > that blue roses best grow in Holland, where there's good > support infrastructure for growing green stuff, while you'd > have to look hard to find any green stuff at all on > Antarctica. 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 agencies and available workers. Could the same business succeed in Somalia as well? Possibly - if it's a bakery or something similarly fundamental. More complex businesses would likely not thrive very well there. *That* is how I think the current Linux kernel tooling landscape looks like currently in a fair number of places: in many aspects it's similar to Somalia - disjunct entities with not much commonality or shared infrastructure. Why people question the desire for a kernel related project (that only runs on a Linux host) to actually be part of an already well working, civilized society (the kernel repo) - for mutual, well documented benefits - instead of having to grow it all itself, is rather perplexing to me... 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 badness happened. Yes, sometimes we broke compatibility as ABI changes/enhancements do - but treated them as regressions and fixed them. I also think that considering the rate of changes our breakage ratio is very good. So no badness happened, and in fact a lot of goodness happened: which goodness never happened while Linux profiling was a separate project isolated as a user-space utility! Anyone opposing integration I think *HAS* to explain the mechanics behind this very example in plain sight. Why the heck has pretty much every other out of tree profiling project died, while the in-tree one is thriving? Yes, the key is that Arnaldo is good, and so are the other perf contributors - and they are good because they feel at home and they are productive. Being in the kernel repo is actually 90% responsible for that environment! > For example, I consider it a *feature* that when we extend the > file system data structures for ext4, [...] I consider filesystems the most extreme example. It's so extreme that it's almost a separate class for itself. Filesystems have the most extreme data persistency constraints possible: they define the ABI and anything that gets written out through them to persistent storage stays there forever and has to work, years down the line. So one must be absolutely, 110% careful - to the level of inventing new validation technologies just to be more careful. *NONE* of that applies to tools/perf/ or tools/kvm/: neither really writes any data structure defined by itself that will be persistent forever. perf.data comes closest, but when was it the last time you used a year old perf.data? I'd say never. It either gets used within a few days or does not get used at all. ( Yet we even keep perf.data compatibility because being careful about data is generally good technology - it's just not *critical*. ) Same goes for tools/kvm/: it has very short data persistency latency as well. Such are in fact most other kernel related utilities. So your 'filesystem utilities' example is totally inapplicable to tools/perf/ and tools/kvm/. Shaping all utilities based on that extreme example is a sad mistake. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 (think KVM ARM port here, for > > example). The secondary argument has been to make it easy > > for kernel developers to work on both userspace and kernel > > in tandem (like has happened with vhost drivers). In short: > > it speeds up development of Linux virtualization code. > > Why? You've made this statement over and over and over again, > and I've dismissed it over and over and over again because I > simply don't think it's true. > > It's simply a statement with nothing to back it up. Why repeat > it? > > 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 makes it so > critical that you get the kernel and kvmtool with a single > pull, and they have to be in sync? [...] 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. [ In hindsight not taking the GGI code 15+ years ago was IMO a (bad) mistake - yet we lived. ] I think it's actively *useful* to the kernel project to have tools/kvm/ - because we already reaped some benefits and have the commit IDs to prove it. If you are asking why it is helpful to the tools/kvm project to be part of the kernel repository then there's plenty of (good) reasons as well. (And because it's the much smaller project, the benefits are much more significant to it than benefits are to the Linux kernel project, relatively. You'll find that to be true with just about any code.) Is any of those reasons of why it's good for tools/kvm/ to be in the kernel repo critical? I think the *combination* is definitely critical. It's very much possible for each factor to seem 'small' in isolation but for the combination to be significant - denying that would be fallacy of composition. Let me list them in case there's anything new that was not said before. Some of the advantages are social, some are technical: 1) 'tooling and kernel side support goes hand in hand' I can best describe this from the tools/perf/ perspective: reviewing new kernel side features that has tooling impact is a *LOT* easier and a lot faster if it comes with readable, functional tooling patches. There's no ifs and whens about it, and that alone makes tools/perf/ worth it to such a degree that we imposed a maintenance rule so that kernel side features always need to come with enabling tooling support. With tools/kvm/ I saw similar effects as well - on a smaller scale, because due to not being upstream tools/kvm/ cannot realistically improve upon ABIs nearly as well as tools/perf/ can. Those effects will strengthen as the project grows. For tools/kvm/ this property is optional, so unlike tools/perf/ you don't see it for every activity there - but there were several examples of that despite its optionality. 2) 'code reuse' We utilize useful kernel code directly in user-space. It starts out ad-hoc and messy (and I still like Al Viro's description of that process back from the tools/perf/ flamewars). We have a tools/kvm/ example of that process in action: for example an upcoming v3.9 feature, the user-space lockdep utility enabled via tools/lib/lockdep/. (Although now you might NAK that, I don't really understand your underlying position here.) I am pretty confident to say that the new liblockdep and the 'lockdep' utility (which checks pthread_mutex and pthread_rwlock locking in user-space - on existing binaries, using LD_PRELOAD), despite having been talked about for years, would simply not have happened without tools/kvm/ present in a kernel repo, full stop. Not this year, not next year, probably not this decade. The reason is that the code needed several unlikely constellations to coincide: - tools/kvm attracted a capable contributor who never wrote kernel code before but who was interested in user-space coding and in virtualization code. - this person, over the past 2 years, learned the ropes and gradually started writing kernel code as well. - he also learned how to interact tooling with the kernel proper. First the messy way, then in gradually less messy ways. - tools/kvm/ uses a user-space equivalent of kernel locking primitives, such a mutex_lock()/mutex_unlock(), so his experience with tools/kvm/ locking helped him kick-start into looking at kernel-side locking. - he got to the level where he would understand lockdep.c, a pretty non-trivial piece of kernel code. - he ended up gradually validating
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 is directly linked to kernel code (think KVM ARM port here, for example). The secondary argument has been to make it easy for kernel developers to work on both userspace and kernel in tandem (like has happened with vhost drivers). In short: it speeds up development of Linux virtualization code. Why? You've made this statement over and over and over again, and I've dismissed it over and over and over again because I simply don't think it's true. It's simply a statement with nothing to back it up. Why repeat it? 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 makes it so critical that you get the kernel and kvmtool with a single pull, and they have to be in sync? [...] 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. [ In hindsight not taking the GGI code 15+ years ago was IMO a (bad) mistake - yet we lived. ] I think it's actively *useful* to the kernel project to have tools/kvm/ - because we already reaped some benefits and have the commit IDs to prove it. If you are asking why it is helpful to the tools/kvm project to be part of the kernel repository then there's plenty of (good) reasons as well. (And because it's the much smaller project, the benefits are much more significant to it than benefits are to the Linux kernel project, relatively. You'll find that to be true with just about any code.) Is any of those reasons of why it's good for tools/kvm/ to be in the kernel repo critical? I think the *combination* is definitely critical. It's very much possible for each factor to seem 'small' in isolation but for the combination to be significant - denying that would be fallacy of composition. Let me list them in case there's anything new that was not said before. Some of the advantages are social, some are technical: 1) 'tooling and kernel side support goes hand in hand' I can best describe this from the tools/perf/ perspective: reviewing new kernel side features that has tooling impact is a *LOT* easier and a lot faster if it comes with readable, functional tooling patches. There's no ifs and whens about it, and that alone makes tools/perf/ worth it to such a degree that we imposed a maintenance rule so that kernel side features always need to come with enabling tooling support. With tools/kvm/ I saw similar effects as well - on a smaller scale, because due to not being upstream tools/kvm/ cannot realistically improve upon ABIs nearly as well as tools/perf/ can. Those effects will strengthen as the project grows. For tools/kvm/ this property is optional, so unlike tools/perf/ you don't see it for every activity there - but there were several examples of that despite its optionality. 2) 'code reuse' We utilize useful kernel code directly in user-space. It starts out ad-hoc and messy (and I still like Al Viro's description of that process back from the tools/perf/ flamewars). We have a tools/kvm/ example of that process in action: for example an upcoming v3.9 feature, the user-space lockdep utility enabled via tools/lib/lockdep/. (Although now you might NAK that, I don't really understand your underlying position here.) I am pretty confident to say that the new liblockdep and the 'lockdep' utility (which checks pthread_mutex and pthread_rwlock locking in user-space - on existing binaries, using LD_PRELOAD), despite having been talked about for years, would simply not have happened without tools/kvm/ present in a kernel repo, full stop. Not this year, not next year, probably not this decade. The reason is that the code needed several unlikely constellations to coincide: - tools/kvm attracted a capable contributor who never wrote kernel code before but who was interested in user-space coding and in virtualization code. - this person, over the past 2 years, learned the ropes and gradually started writing kernel code as well. - he also learned how to interact tooling with the kernel proper. First the messy way, then in gradually less messy ways. - tools/kvm/ uses a user-space equivalent of kernel locking primitives, such a mutex_lock()/mutex_unlock(), so his experience with tools/kvm/ locking helped him kick-start into looking at kernel-side locking. - he got to the level where he would understand lockdep.c, a pretty non-trivial piece of kernel code. - he ended up
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 extreme badness happened. Yes, sometimes we broke compatibility as ABI changes/enhancements do - but treated them as regressions and fixed them. I also think that considering the rate of changes our breakage ratio is very good. So no badness happened, and in fact a lot of goodness happened: which goodness never happened while Linux profiling was a separate project isolated as a user-space utility! Anyone opposing integration I think *HAS* to explain the mechanics behind this very example in plain sight. Why the heck has pretty much every other out of tree profiling project died, while the in-tree one is thriving? Yes, the key is that Arnaldo is good, and so are the other perf contributors - and they are good because they feel at home and they are productive. Being in the kernel repo is actually 90% responsible for that environment! For example, I consider it a *feature* that when we extend the file system data structures for ext4, [...] I consider filesystems the most extreme example. It's so extreme that it's almost a separate class for itself. Filesystems have the most extreme data persistency constraints possible: they define the ABI and anything that gets written out through them to persistent storage stays there forever and has to work, years down the line. So one must be absolutely, 110% careful - to the level of inventing new validation technologies just to be more careful. *NONE* of that applies to tools/perf/ or tools/kvm/: neither really writes any data structure defined by itself that will be persistent forever. perf.data comes closest, but when was it the last time you used a year old perf.data? I'd say never. It either gets used within a few days or does not get used at all. ( Yet we even keep perf.data compatibility because being careful about data is generally good technology - it's just not *critical*. ) Same goes for tools/kvm/: it has very short data persistency latency as well. Such are in fact most other kernel related utilities. So your 'filesystem utilities' example is totally inapplicable to tools/perf/ and tools/kvm/. Shaping all utilities based on that extreme example is a sad mistake. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 modifications to kernel/lockdep.c enabled it to be librarified, and then the remaining work was done in user-space - here too in successive steps. - tools/kvm/ happened to be hosted in the same kernel repo that the locking tree is hosted in. The end result is something good that I never saw happen to kernel code before, in the last 20 years of the Linux kernel. Maybe it could have happened with an outside tools/kvm repo, but I very strongly suspect that it would not. In theory this could have been done in the cold, fragmented, isolated and desolate landscape of Linux user-space utilities, by copying kernel/lockdep.c and a handful of kernel headers to user-space, and making it work there somehow. Just like a blue rose could in theory grow on Antarctica as well, given the right set of circumstances. It just so happens that blue roses best grow in Holland, where there's good support infrastructure for growing green stuff, while you'd have to look hard to find any green stuff at all on Antarctica. 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 agencies and available workers. Could the same business succeed in Somalia as well? Possibly - if it's a bakery or something similarly fundamental. More complex businesses would likely not thrive very well there. *That* is how I think the current Linux kernel tooling landscape looks like currently in a fair number of places: in many aspects it's similar to Somalia - disjunct entities with not much commonality or shared infrastructure. Why people question the desire for a kernel related project (that only runs on a Linux host) to actually be part of an already well working, civilized society (the kernel repo) - for mutual, well documented benefits - instead of having to grow it all itself, is rather perplexing to me... 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 agencies and available workers. Could the same business succeed in Somalia as well? Possibly - if it's a bakery or something similarly fundamental. More complex businesses would likely not thrive very well there. *That* is how I think the current Linux kernel tooling landscape looks like currently in a fair number of places: in many aspects it's similar to Somalia - disjunct entities with not much commonality or shared infrastructure. 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. And for code-reuse it's even easy enough to automatically extract parts of kernel code into a separate repository. See the ecos-jffs2 and linux-headers trees, for example, which automatically tracked Linus' tree with a certain transformation to make them sane for just pulling into the relevant target repositories. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
[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 for x86. Now if you look at this: https://github.com/penberg/linux-kvm/commit/051bdb63879385e12b7e253b72cdde909a5e0b9b There are other platforms added. Look here: https://wiki.linaro.org/LEG/Engineering/Virtualization [quote]kvmtool is used meanwhile[/quote] They are using it ! On Mon, Feb 11, 2013 at 3:18 PM, 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 infrastructure, trust, distribution, standards, enforcement agencies and available workers. Could the same business succeed in Somalia as well? Possibly - if it's a bakery or something similarly fundamental. More complex businesses would likely not thrive very well there. *That* is how I think the current Linux kernel tooling landscape looks like currently in a fair number of places: in many aspects it's similar to Somalia - disjunct entities with not much commonality or shared infrastructure. 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. And for code-reuse it's even easy enough to automatically extract parts of kernel code into a separate repository. See the ecos-jffs2 and linux-headers trees, for example, which automatically tracked Linus' tree with a certain transformation to make them sane for just pulling into the relevant target repositories. -- dwmw2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 some point. On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar mi...@kernel.org wrote: What if somebody tells you that they are really tired of Xen, and actually want to turn kvmtool into *replacement* for Xen instead? [...] Actually, this was raised by some people - and I think some generalization patches were applied already but Pekka might know more about that ... There was some interest but I don't think anybody sent patches for that. There's no fundamental reason why we couldn't support Xen if people are interested in working on that. Pekka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 kvmtool, and quite frankly, I DO NOT CARE. Everything you talk about is about helping your work, by making the kernel maintenance be more. The fact that you want to use kernel infrastructure in kvmtool is a great example: you may think it's a great thing, but for the kernel it's just extra work, and extra layers of abstraction etc etc. And then you make it clear that you haven't even *bothered* to try to make it a separate project. Sorry, but with that kind of approach, I get less and less interested. I think this whole tying together is a big mistake. It encourages linkages that simply shouldn't be there. And no, perf is not the perfect counter-example. With perf,. the linkages made sense! There's supposed to be deep linkages to profiling and event counting. There is ABSOLUTELY NOT supposed to be deep linkages with virtualization. Quite the reverse. And no, I don't want to maintain the mess that is both. There's just no gain, and lots of potential pain. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 kernel repo. Exactly. I do *not* want a abstraction layer just because somebody wants to use it. It causes idiotic guards in the header files etc. We already had that pain with the user-level header inclusions etc. Just copy it. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 Windows. But yeah, we'll hopefully support non-Linux guest at some point. digression You're probably better off focusing on OVMF rather than just SeaBIOS. SeaBIOS has CSM support now, so it can provide 'legacy' BIOS services under OVMF. So if OVMF runs, you get both EFI and legacy support. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 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. digression You're probably better off focusing on OVMF rather than just SeaBIOS. SeaBIOS has CSM support now, so it can provide 'legacy' BIOS services under OVMF. So if OVMF runs, you get both EFI and legacy support. -- dwmw2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 that decision is a mistake. You go on to explain how this helps kvmtool, and quite frankly, I DO NOT CARE. Me and Pekka also listed several examples of how it already helped the kernel, despite it only being partially present in some kernel repos: - Pekka listed new virtio drivers that were done via tools/kvm. - Pekka listed ARM KVM support which was written/prototyped using tools/kvm. - There's over a dozen bugfixes in your kernel which were found via syscall fuzzing built into tools/kvm. (I can dig them all out if you want.) - There are several fixes in the kernel side KVM subsystem itself that were unearthed via tools/kvm. - I showed how it helped the kernel by creating user-space lockdep: code used in more situations means more exposure, more bugfixes and more contributors. (It also allowed immediate lockdep coverage for all the user-space mutexes that tools/perf/ itself uses.) Those were all real benefits to the kernel which are upstream or almost upstream today. This tool alone generated a *more* versatile number of improvements to the kernel than the majority of filesystems and the majority of drivers in the Linux kernel tree today has ever achieved. How on earth can anyone, against all that evidence, still claim that it's a net minus? Everything you talk about is about helping your work, by making the kernel maintenance be more. The fact that you want to use kernel infrastructure in kvmtool is a great example: you may think it's a great thing, but for the kernel it's just extra work, and extra layers of abstraction etc etc. At least in the case of lockdep, the kernel side change enabling it was a trivial: kernel/lockdep.c | 4 1 file changed, 4 insertions(+) ... but we could probably make even that interaction go away and make it exactly zero, and push all the changes on to the liblockdep side. Anyway, should I consider user space lockdep NAK-ed too in this form, before we put any more work into it? And then you make it clear that you haven't even *bothered* to try to make it a separate project. Just like back in the days you haven't even bothered to make Linux a proper GNU project, and for good reasons. Nor have I ever tried to write scheduler code for another OS. Some expensive, disruptive things you don't try because you disagree with the model, on what you think to be valid grounds. You make a judgement call, you take your chances, and you see whether it works. Sorry, but with that kind of approach, I get less and less interested. I think this whole tying together is a big mistake. It encourages linkages that simply shouldn't be there. And no, perf is not the perfect counter-example. With perf,. the linkages made sense! There's supposed to be deep linkages to profiling and event counting. There is ABSOLUTELY NOT supposed to be deep linkages with virtualization. Quite the reverse. I'm *really* surprised that you say that. perf interfaces to the Linux kernel in a very similar way to how tools/kvm interfaces to the Linux kernel: both use (very) Linux specific system calls to run on a host system running the Linux kernel. Neither tool will in the foreseeable future execute on any other, non-Linux host kernel. ( Running non-Linux guest OS's is an entirely different matter and there's no fundamental restriction there. ) tools/perf/ is not in the kernel because it interfaces with the kernel in nasty, incestous ways. It is in the kernel mainly because that's the contribution model that turned out to work well for both the kernel and the tooling side: I initially made the user-space bits of perf a separate project. I didn't run it in that form for a long time, but I got essentially zero contributions. The moment it went into a silly directory in Documentation/perf_counters/, contributions started trickling in. Today it's fully embraced by the kernel side subsystem and allows very efficient interface enhancements on the kernel and tooling side, in lock-step - benefiting both sides significantly. And no, I don't want to maintain the mess that is both. There's just no gain, and lots of potential pain. I disagree, and I don't see the validity of most of your arguments, but it's obviously your call. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 example. There's no need to be *in* the kernel repo. Exactly. I do *not* want a abstraction layer just because somebody wants to use it. It causes idiotic guards in the header files etc. We already had that pain with the user-level header inclusions etc. Just copy it. The UAPI work and make headers_install already has cleaned things up immensely. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 infrastructure, trust, distribution, standards, enforcement agencies and available workers. Could the same business succeed in Somalia as well? Possibly - if it's a bakery or something similarly fundamental. More complex businesses would likely not thrive very well there. *That* is how I think the current Linux kernel tooling landscape looks like currently in a fair number of places: in many aspects it's similar to Somalia - disjunct entities with not much commonality or shared infrastructure. That's complete nonsense. If you want to use pieces of the kernel infrastructure, then just *take* them. [...] So I can take the mailing lists and the whole contribution culture? Hardly... I was not talking about code alone, I was also talking about a social environment - which is not a one sided relationship at all, it improves the kernel code, like it already did for over two dozen tools/kvm originated patches: To quote from my mail to Linus: - Pekka listed new virtio drivers that were done via tools/kvm. - Pekka listed ARM KVM support which was written/prototyped using tools/kvm. - There's over a dozen bugfixes in your kernel which were found via syscall fuzzing built into tools/kvm. (I can dig them all out if you want.) - There are several fixes in the kernel side KVM subsystem itself that were unearthed via tools/kvm. - I showed how it helped the kernel by creating user-space lockdep: code used in more situations means more exposure, more bugfixes and more contributors. (It also allowed immediate lockdep coverage for all the user-space mutexes that tools/perf/ itself uses.) Those were all real benefits to the kernel which are upstream or almost upstream today. This tool alone generated a *more* versatile number of improvements to the kernel than the majority of filesystems and the majority of drivers in the Linux kernel tree today has ever achieved. [...] There are loads of projects which use the kernel config tools, for example. There's no need to be *in* the kernel repo. And for code-reuse it's even easy enough to automatically extract parts of kernel code into a separate repository. [...] ... which solution would: - lose all history - lose contributor awareness of each other - lose easy cross-contribution pathways That's a severe net minus in my opinion. I think you should try to answer the very fundamental observation I made and the question I asked in my mail to Tytso: We have first hand experience there: tools/perf/. None of the predicted extreme badness happened. Yes, sometimes we broke compatibility as ABI changes/enhancements do - but treated them as regressions and fixed them. I also think that considering the rate of changes our breakage ratio is very good. So no badness happened, and in fact a lot of goodness happened: which goodness never happened while Linux profiling was a separate project isolated as a user-space utility! Anyone opposing integration I think *HAS* to explain the mechanics behind this very example in plain sight. Why the heck has pretty much every other out of tree profiling project died, while the in-tree one is thriving? Yes, the key is that Arnaldo is good, and so are the other perf contributors - and they are good because they feel at home and they are productive. Being in the kernel repo is actually 90% responsible for that environment! And yes, based on the evidence I think much of perf's current vitality would be killed off or would be severely reduced if it was forced into a separate, out of tree project. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 not just make it separate? Everything you claim is such a big deal would still work perfectly well. Every time you talk about negative it's as of the project wouldn't exist if it was external. Which is total bull, since it is effectively external already. [...] That's not actually true. If you check the list of early tools/kvm/ contributors you will see an overlap with -tip contributors. I know tools/kvm/ developers who just use their existing -tip repo to pick up the latest. They are using the -tip commit notifications to see what went in and what not, etc. Claiming that because the contribution model works to a certain degree integrated into a small Linux subsystem tree it does not ever have to go upstream is so wrong on so many levels ... The most likely correct statement would be something like: if it worked on a small scale it will probably work even better with more exposure on a larger scale. We'll never know that though. ( That is also why some of the focus was on lockdep - knowing that it's close in terms of maintenance distance made it an easier topic - socially. ) Since I'm using it on an almost daily basis to test out failed bzImages, and because I (mistakenly) thought it had some upstream chances, I found it good to help out (a bit) with maintenance and code review. While it works it's obviously limited - there's just so many -tip developers and I thought everyone would benefit from this going the next natural step. [...] And it will stay that way. You are just in denial and trying to say that integrating it would somehow help. And I claim it wouldn't. It works fine outside already. Just ADMIT it. So tools/kvm/ works 'just fine' - in its current limited form - because for the developers involved it's already upstream, for the first hop of upstream. 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 keep the 'tit' only though. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 wants to keep the 'tit' only though. Ingo, stop this idiotic nonsense. You seem to think that kvmtool is useful for kernel is somehow relevant. IT IS TOTALLY IRRELEVANT. sparse is useful for kernel development. git is useful for kernel development. xterm is useful for kernel development. See a pattern? We have tons of tools that are helping develop the kernel, and for absolutely NONE of them is that at all an argument for merging them into the kernel. If the Xen people came and asked me to merge their virtualizer code into the kernel, I'd call them idiots. Why is kvmtool so magical that you use this argument for merging it into the kernel? It makes no sense. Yet you continue to use it as if it was somehow an argument for merging it. Despite the hundreds of projects to the contrary. So this whole constant stream of benefits you talk about is PURE AND UTTER GARBAGE. And that's not a commentary on whether it is true or not, it's a commentary on the fact that it is entirely irrelevant to whether something should be merged. Merging two projects does not make them easier to maintain. Quite the reverse. It just ties the maintenance together in irrelevant ways. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 makes it so critical that you get the kernel and > kvmtool with a single pull, and they have to be in sync? When you then > at the same time claim that you make very sure that they don't have to > be in sync at all. See your earlier emails about how you claim to have > worked very hard to make sure they work across different versions. 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. For example, I consider it a *feature* that when we extend the file system data structures for ext4, they have to be made in the two places; once in the kernel, and once in e2fsprogs's version of ext2_fs.h. Yes, it might be more convenient if we pushed all of e2fsprogs into the kernel, so I wouldn't have to edit ext2_fs.h in two places, but when I make changes to ext2_fs.h, I want to be really careful, lest I not break backwards compatibility, and to think very carefully about forward compatibility issues. If there are constantly huge numbers of interface changes in the kernel/userspace interface, then it increases the chances that mistakes will be made. It's better that those mistakes be caught early, and if changes need to be made in two places, it increases the chances that these mistakes will be noticed sooner rather than later. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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). The secondary argument has been to make it easy for kernel > developers > to work on both userspace and kernel in tandem (like has happened with vhost > drivers). In short: it speeds up development of Linux virtualization code. Why? You've made this statement over and over and over again, and I've dismissed it over and over and over again because I simply don't think it's true. It's simply a statement with nothing to back it up. Why repeat it? 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 makes it so critical that you get the kernel and kvmtool with a single pull, and they have to be in sync? When you then at the same time claim that you make very sure that they don't have to be in sync at all. See your earlier emails about how you claim to have worked very hard to make sure they work across different versions. So you make these unsubstantiated claims about how much easier it is, and they make no sense. You never explain *why* it's so magically easier. Is git so hard to use that you can't do "git pull" twice? And why would you normally even *want* to do git pull twice? 99% of the work in the kernel has nothing what-so-ever to do with kvmtool, and hopefully the reverse is equally true. And tying into the kernel just creates this myopic world of only looking at the current kernel. What if somebody decides that they actually want to try to boot Windows with kvmtool? What if somebody tells you that they are really tired of Xen, and actually want to turn kvmtool into *replacement* for Xen instead? What if somebody wants to branch off their own work, concentrating on some other issue entirely, and wants to merge with upstream kvmtool but not worry about the kernel, because they aren't working on the Linux kernel at all, and their work is about something else? I just don't think it makes sense. I don't see what the huge advantage of a single git tree is. Anyway, I'm done arguing. You can do what you want, but just stop misrepresenting it as being "linux-next" material unless you are willing to actually explain why it should be so. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 the only one working on it, so being > convenient for you is the primary issue. Arguments like that actively > make me not want to merge it, because they are only arguments for you > continuing to work the way you have, not arguments for why the project > would make sense to merge into the main kernel repository. You are so full of shit it's not even funny. I am *not* the only person working on the project, far from it. I'm not trying to make things easy for me, I'm trying to build on the strenghts of tools/kvm. 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). The secondary argument has been to make it easy for kernel developers to work on both userspace and kernel in tandem (like has happened with vhost drivers). In short: it speeds up development of Linux virtualization code. It's not as if there's anything new here so I didn't think it was necessary to rehash the old arguments. I know you don't have a compelling reason to pull and that's fine. Just don't come up with these lame excuses that have nothing to do with reality. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 project, so it doesn't compile that way. You're the only one working on it, so being convenient for you is the primary issue. Arguments like that actively make me not want to merge it, because they are only arguments for you continuing to work the way you have, not arguments for why the project would make sense to merge into the main kernel repository. So I think we should just remove this from linux-next, and be done with the fantasy that it makes sense to merge this. You're not even trying to convince anybody else about the merge making sense. You might as well continue to work the way you do, and I don't mind - but none of it argues for me merging it into the kernel. There's no reason why kvmtool couldn't be external the way all the other virtualization projects are. Linus On Feb 9, 2013 2:01 AM, "Pekka Enberg" wrote: > > 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 folks easy. > > In fact that's something Ingo pushed for pretty hard early on and we > also worked hard just to make the code 'feel familiar' to kernel folks. > The assumption was that if we did that, we'd see contributions from > people who would normally not write userspace code. > > On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds > wrote: > > The merged case seems to make sense for you and Ingo, and nobody else. > > That's hardly surprising. I'm the only person who was crazy enough to > listen to Ingo and follow through with the damn thing. So I either have > the same experience and perspective as Ingo does on the matter - or I'm > just as full of 'bullshit' as he is. > > On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds > wrote: > > The only thing the lock-step does is to generate the kind of > > dependency that I ABSOLUTELY DETEST, where one version of kvmtools > > goes along with one version of the kernel. > > That is simply NOT TRUE. We have never done such a thing with 'kvmtool' > nor I have any evidence that 'perf' has done that either. I regularily > run old versions to make sure that we stay that way. > > On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds > wrote: > > So you can't have it both ways. What's so wrong with just making it a > > separate project? > > Do you really think it's an option I have not considered several times? > > There are the immediate practical problems: > > - What code should we take with us from the Linux repository. If I take > just tools/kvm, it won't even build. > > - Where do we do our development? Right now we are using the KVM list > and are part of tip tree workflow. As a separate project, we need to > build the kind of infrastructure we already are relying on now. > > Then there are the long term issues: > > - How do we keep up with KVM and virtio improvements? > > - How do we ensure we get improvements that happened in the kernel > tree to our codebase for the code we share? > > - How do we make it easy for future KVM and virtio developers to > access our code? > > If you want perspective on this just ask Ingo sometime how he feels > about making tools/perf a separate project (which I have actually done). > Much of the *practical* aspects applies to tools/kvm. > > And really, I'm a practical kind of guy. Why do you think I'm willing to > bang to my head to the wall if spinning off as a separate project would > be as simple as you seem to think it is? > > Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 folks easy. In fact that's something Ingo pushed for pretty hard early on and we also worked hard just to make the code 'feel familiar' to kernel folks. The assumption was that if we did that, we'd see contributions from people who would normally not write userspace code. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds wrote: > The merged case seems to make sense for you and Ingo, and nobody else. That's hardly surprising. I'm the only person who was crazy enough to listen to Ingo and follow through with the damn thing. So I either have the same experience and perspective as Ingo does on the matter - or I'm just as full of 'bullshit' as he is. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds wrote: > The only thing the lock-step does is to generate the kind of > dependency that I ABSOLUTELY DETEST, where one version of kvmtools > goes along with one version of the kernel. That is simply NOT TRUE. We have never done such a thing with 'kvmtool' nor I have any evidence that 'perf' has done that either. I regularily run old versions to make sure that we stay that way. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds wrote: > So you can't have it both ways. What's so wrong with just making it a > separate project? Do you really think it's an option I have not considered several times? There are the immediate practical problems: - What code should we take with us from the Linux repository. If I take just tools/kvm, it won't even build. - Where do we do our development? Right now we are using the KVM list and are part of tip tree workflow. As a separate project, we need to build the kind of infrastructure we already are relying on now. Then there are the long term issues: - How do we keep up with KVM and virtio improvements? - How do we ensure we get improvements that happened in the kernel tree to our codebase for the code we share? - How do we make it easy for future KVM and virtio developers to access our code? If you want perspective on this just ask Ingo sometime how he feels about making tools/perf a separate project (which I have actually done). Much of the *practical* aspects applies to tools/kvm. And really, I'm a practical kind of guy. Why do you think I'm willing to bang to my head to the wall if spinning off as a separate project would be as simple as you seem to think it is? Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 making development for kernel folks easy. In fact that's something Ingo pushed for pretty hard early on and we also worked hard just to make the code 'feel familiar' to kernel folks. The assumption was that if we did that, we'd see contributions from people who would normally not write userspace code. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds torva...@linux-foundation.org wrote: The merged case seems to make sense for you and Ingo, and nobody else. That's hardly surprising. I'm the only person who was crazy enough to listen to Ingo and follow through with the damn thing. So I either have the same experience and perspective as Ingo does on the matter - or I'm just as full of 'bullshit' as he is. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds torva...@linux-foundation.org wrote: The only thing the lock-step does is to generate the kind of dependency that I ABSOLUTELY DETEST, where one version of kvmtools goes along with one version of the kernel. That is simply NOT TRUE. We have never done such a thing with 'kvmtool' nor I have any evidence that 'perf' has done that either. I regularily run old versions to make sure that we stay that way. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds torva...@linux-foundation.org wrote: So you can't have it both ways. What's so wrong with just making it a separate project? Do you really think it's an option I have not considered several times? There are the immediate practical problems: - What code should we take with us from the Linux repository. If I take just tools/kvm, it won't even build. - Where do we do our development? Right now we are using the KVM list and are part of tip tree workflow. As a separate project, we need to build the kind of infrastructure we already are relying on now. Then there are the long term issues: - How do we keep up with KVM and virtio improvements? - How do we ensure we get improvements that happened in the kernel tree to our codebase for the code we share? - How do we make it easy for future KVM and virtio developers to access our code? If you want perspective on this just ask Ingo sometime how he feels about making tools/perf a separate project (which I have actually done). Much of the *practical* aspects applies to tools/kvm. And really, I'm a practical kind of guy. Why do you think I'm willing to bang to my head to the wall if spinning off as a separate project would be as simple as you seem to think it is? Pekka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 project, so it doesn't compile that way. You're the only one working on it, so being convenient for you is the primary issue. Arguments like that actively make me not want to merge it, because they are only arguments for you continuing to work the way you have, not arguments for why the project would make sense to merge into the main kernel repository. So I think we should just remove this from linux-next, and be done with the fantasy that it makes sense to merge this. You're not even trying to convince anybody else about the merge making sense. You might as well continue to work the way you do, and I don't mind - but none of it argues for me merging it into the kernel. There's no reason why kvmtool couldn't be external the way all the other virtualization projects are. Linus On Feb 9, 2013 2:01 AM, Pekka Enberg penb...@kernel.org wrote: 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 making development for kernel folks easy. In fact that's something Ingo pushed for pretty hard early on and we also worked hard just to make the code 'feel familiar' to kernel folks. The assumption was that if we did that, we'd see contributions from people who would normally not write userspace code. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds torva...@linux-foundation.org wrote: The merged case seems to make sense for you and Ingo, and nobody else. That's hardly surprising. I'm the only person who was crazy enough to listen to Ingo and follow through with the damn thing. So I either have the same experience and perspective as Ingo does on the matter - or I'm just as full of 'bullshit' as he is. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds torva...@linux-foundation.org wrote: The only thing the lock-step does is to generate the kind of dependency that I ABSOLUTELY DETEST, where one version of kvmtools goes along with one version of the kernel. That is simply NOT TRUE. We have never done such a thing with 'kvmtool' nor I have any evidence that 'perf' has done that either. I regularily run old versions to make sure that we stay that way. On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds torva...@linux-foundation.org wrote: So you can't have it both ways. What's so wrong with just making it a separate project? Do you really think it's an option I have not considered several times? There are the immediate practical problems: - What code should we take with us from the Linux repository. If I take just tools/kvm, it won't even build. - Where do we do our development? Right now we are using the KVM list and are part of tip tree workflow. As a separate project, we need to build the kind of infrastructure we already are relying on now. Then there are the long term issues: - How do we keep up with KVM and virtio improvements? - How do we ensure we get improvements that happened in the kernel tree to our codebase for the code we share? - How do we make it easy for future KVM and virtio developers to access our code? If you want perspective on this just ask Ingo sometime how he feels about making tools/perf a separate project (which I have actually done). Much of the *practical* aspects applies to tools/kvm. And really, I'm a practical kind of guy. Why do you think I'm willing to bang to my head to the wall if spinning off as a separate project would be as simple as you seem to think it is? Pekka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 compile that way. You're the only one working on it, so being convenient for you is the primary issue. Arguments like that actively make me not want to merge it, because they are only arguments for you continuing to work the way you have, not arguments for why the project would make sense to merge into the main kernel repository. You are so full of shit it's not even funny. I am *not* the only person working on the project, far from it. I'm not trying to make things easy for me, I'm trying to build on the strenghts of tools/kvm. 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). The secondary argument has been to make it easy for kernel developers to work on both userspace and kernel in tandem (like has happened with vhost drivers). In short: it speeds up development of Linux virtualization code. It's not as if there's anything new here so I didn't think it was necessary to rehash the old arguments. I know you don't have a compelling reason to pull and that's fine. Just don't come up with these lame excuses that have nothing to do with reality. Pekka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 example). The secondary argument has been to make it easy for kernel developers to work on both userspace and kernel in tandem (like has happened with vhost drivers). In short: it speeds up development of Linux virtualization code. Why? You've made this statement over and over and over again, and I've dismissed it over and over and over again because I simply don't think it's true. It's simply a statement with nothing to back it up. Why repeat it? 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 makes it so critical that you get the kernel and kvmtool with a single pull, and they have to be in sync? When you then at the same time claim that you make very sure that they don't have to be in sync at all. See your earlier emails about how you claim to have worked very hard to make sure they work across different versions. So you make these unsubstantiated claims about how much easier it is, and they make no sense. You never explain *why* it's so magically easier. Is git so hard to use that you can't do git pull twice? And why would you normally even *want* to do git pull twice? 99% of the work in the kernel has nothing what-so-ever to do with kvmtool, and hopefully the reverse is equally true. And tying into the kernel just creates this myopic world of only looking at the current kernel. What if somebody decides that they actually want to try to boot Windows with kvmtool? What if somebody tells you that they are really tired of Xen, and actually want to turn kvmtool into *replacement* for Xen instead? What if somebody wants to branch off their own work, concentrating on some other issue entirely, and wants to merge with upstream kvmtool but not worry about the kernel, because they aren't working on the Linux kernel at all, and their work is about something else? I just don't think it makes sense. I don't see what the huge advantage of a single git tree is. Anyway, I'm done arguing. You can do what you want, but just stop misrepresenting it as being linux-next material unless you are willing to actually explain why it should be so. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 makes it so critical that you get the kernel and kvmtool with a single pull, and they have to be in sync? When you then at the same time claim that you make very sure that they don't have to be in sync at all. See your earlier emails about how you claim to have worked very hard to make sure they work across different versions. 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. For example, I consider it a *feature* that when we extend the file system data structures for ext4, they have to be made in the two places; once in the kernel, and once in e2fsprogs's version of ext2_fs.h. Yes, it might be more convenient if we pushed all of e2fsprogs into the kernel, so I wouldn't have to edit ext2_fs.h in two places, but when I make changes to ext2_fs.h, I want to be really careful, lest I not break backwards compatibility, and to think very carefully about forward compatibility issues. If there are constantly huge numbers of interface changes in the kernel/userspace interface, then it increases the chances that mistakes will be made. It's better that those mistakes be caught early, and if changes need to be made in two places, it increases the chances that these mistakes will be noticed sooner rather than later. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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. Quite frankly, that's just optimizing for the wrong case. The merged case seems to make sense for you and Ingo, and nobody else. And then you wonder why nobody else wants to merge it. I've told you my reasons, you didn't give me *any* actual reasons for me to merge the code. NONE of your statements made any sense at all, since everything you talk about could have been done with a separate project. The only thing the lock-step does is to generate the kind of dependency that I ABSOLUTELY DETEST, where one version of kvmtools goes along with one version of the kernel. That's a huge disadvantage (and we've actually seen signs of that in the perf tool too, where old versions of the tools have been broken, because the people working on them have been way too much in lock-step with the kernel it is used on). And if it's not the case that they have to be used in lockstep, then clearly kvmtool developers could just as easily just have a separate git repository. So you can't have it both ways. What's so wrong with just making it a separate project? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 tie two > projects together that just shouldn't be tied together. The two are already tied together - that was the whole premise of the project! What Ingo proposed two years ago was to implement a (simple) userspace counterpart of KVM under tools/kvm using kernel development process and reusing kernel code as much as possible. He predicted that we'd eventually have: - a clean codebase that's accessible to new developers - new kernel features developed in 'lock-step' with the userspace code - encouraged kernel developers to write userspace code As it turns out, Ingo's predictions were correct. We support KVM on ARMv8 even before the in-kernel code has hit mainline. People implemented vhost drivers in lock-step. Most of the contributors are also kernel developers. And we in fact have a clean codebase that's accessible to anyone who knows the kernel coding style. I honestly don't see any of these things happening had we not taken the path suggested by Ingo early on. On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds wrote: > The fact that kvmtool isn't available as a standalone project probably > keeps people actively from using it. You can't just fetch kvmtool. You > have to fetch the kernel and kvmtool, and if you're a kernel developer > you either have to make a whole new kernel tree for it (which is > stupid) or merge it into your normal kernel tree that has development > that has nothing to do with kvmtool (which is stupid AND F*CKING > INSANE) Actually, as a kernel developer, you don't need to do that. You can 'make install' from a kvmtool branch and leave it at that - just like with perf. [ And if it was in your tree, you'd wouldn't even need the branch ;-). ] 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. On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds wrote: > "git" is a hell of a lot more useful utility for kernel development, > to the point that practically we couldn't do without it any more, and > it isn't merged into the kernel. It's a separate project with a > separate life, and it is *better* for it. Sure but the difference between "git" and kvmtool is that a significant chuck of kvmtool development is directly related to in-kernel KVM and device drivers. That's why I've argued from day one that tools/kvm is 'special'. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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" could be a reason, and then people posted five-liner scripts to give some of the other virtual boxes the same kind of interface. Avoiding five lines of shell script is not a reason to pull a project into the kernel. > tools/kvm/ is a useful utility to kernel development, that in > just this past cycle was used as an incubator to: That's total bullshit. It could be useful whether it is merged into the kernel or not. "git" is a hell of a lot more useful utility for kernel development, to the point that practically we couldn't do without it any more, and it isn't merged into the kernel. It's a separate project with a separate life, and it is *better* for it. The same goes for all the tools that everybody uses every day for kernel development, often without even thinking about them. So "utility to kernel development" is not a reason for merging it into the kernel. NOT AT ALL. > *Please* don't try to harm useful code just for the heck of it. Again, total *bullshit*. Right now, the whole "attach the kvmtool to the kernel as a remora" doesn't make any sense at all, and not merging it doesn't harm anything AT ALL. Quite the reverse. The fact that kvmtool isn't available as a standalone project probably keeps people actively from using it. You can't just fetch kvmtool. You have to fetch the kernel and kvmtool, and if you're a kernel developer you either have to make a whole new kernel tree for it (which is stupid) or merge it into your normal kernel tree that has development that has nothing to do with kvmtool (which is stupid AND F*CKING INSANE) > Please stop this silliness, IMO it's not constructive at all ... Ingo, it's not us being silly, it is *you*. What the heck is the advantage of merging it into the kernel? It has never ever been explained. This is not like "perf", where there wasn't any alternatives, and oprofile had shown over many many years that the situation wasn't improving: it was only getting worse, and more disconnected from the actual capabilities of the hardware. But kvmtool is no "perf". There are other virtual boxes, and rather than being limited, they are more capable! The selling tool of kvmtool was never that it did something particularly magical, it was always that it did less, and was easier to use. But that does not in any way mean "should be merged". You can do less and be easier to use and stand on your own legs. So here, let me state it very very clearly: I will not be merging kvmtool. It's not about "useful code". It's not about the project keeping to improve. Both of those would seem to be *better* outside the kernel, where there isn't that artificial and actually harmful tie-in. In other words, I don't see *any* advantage to merging kvmtool. I think merging it would be an active mistake, and would just tie two projects together that just shouldn't be tied together. So nobody is "hurting useful code", except perhaps you. Explain to me why I'm wrong. I don't think you can. You certainly haven't so far. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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) for Linus to pull. So far it has over three dozen contributors, most of the commits come from active kernel developers. > > 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 to remove it from your tree, I just would > like it removed from that branch that is included in > linux-next (tip/auto-latest). I know others who also use it > for testing. tip:master and tip:auto-latest are one and the same (with a time delay), so that I can merge faster to linux-next, and so that linux-next can benefit from the strong coverage testing of -tip. > > Note that I never actually had any maintenance problems due > > to it: it's orthogonal, and as long as you don't use it > > explicitly (such as its 'make kvmconfig' feature - which is > > rather handy) it never actually broke anything. > > I don't doubt any of that, it is just that Linus has > explicitly said that he will not pull it into his tree. Thus, > it should not be in linux-next. I'll remove it if Linus insists on it, but I think you guys are putting form before substance and utility :-( tools/kvm/ is a useful utility to kernel development, that in just this past cycle was used as an incubator to: - port KVM functionality to a new architecture - port lockdep to user-space - test bzImages before booting them on real hardware It was also used to prototype kernel features in the past. It's a project that is alive and useful. While there's a metric ton of crap in the kernel, which is not useful to anyone, which has ongoing costs, and which nobody here complains about. What harm has tools/kvm/ done to you? I just checked, in the past it has not broken linux-next *once* - this current thread is about tools/kvm/ funcionality (for which Pekka has already applied the fix). *Please* don't try to harm useful code just for the heck of it. As long as the project keeps improving and as long as Pekka keeps trying his luck with the upstream merge in the next merge window, and as long as its benefits overweigh its costs, I see no reason not to include it - I am eating my own dog food. Please stop this silliness, IMO it's not constructive at all ... 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 useful/interesting enough (yet) for Linus to pull. So far it has over three dozen contributors, most of the commits come from active kernel developers. 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 to remove it from your tree, I just would like it removed from that branch that is included in linux-next (tip/auto-latest). I know others who also use it for testing. tip:master and tip:auto-latest are one and the same (with a time delay), so that I can merge faster to linux-next, and so that linux-next can benefit from the strong coverage testing of -tip. Note that I never actually had any maintenance problems due to it: it's orthogonal, and as long as you don't use it explicitly (such as its 'make kvmconfig' feature - which is rather handy) it never actually broke anything. I don't doubt any of that, it is just that Linus has explicitly said that he will not pull it into his tree. Thus, it should not be in linux-next. I'll remove it if Linus insists on it, but I think you guys are putting form before substance and utility :-( tools/kvm/ is a useful utility to kernel development, that in just this past cycle was used as an incubator to: - port KVM functionality to a new architecture - port lockdep to user-space - test bzImages before booting them on real hardware It was also used to prototype kernel features in the past. It's a project that is alive and useful. While there's a metric ton of crap in the kernel, which is not useful to anyone, which has ongoing costs, and which nobody here complains about. What harm has tools/kvm/ done to you? I just checked, in the past it has not broken linux-next *once* - this current thread is about tools/kvm/ funcionality (for which Pekka has already applied the fix). *Please* don't try to harm useful code just for the heck of it. As long as the project keeps improving and as long as Pekka keeps trying his luck with the upstream merge in the next merge window, and as long as its benefits overweigh its costs, I see no reason not to include it - I am eating my own dog food. Please stop this silliness, IMO it's not constructive at all ... 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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* ease of use could be a reason, and then people posted five-liner scripts to give some of the other virtual boxes the same kind of interface. Avoiding five lines of shell script is not a reason to pull a project into the kernel. tools/kvm/ is a useful utility to kernel development, that in just this past cycle was used as an incubator to: That's total bullshit. It could be useful whether it is merged into the kernel or not. git is a hell of a lot more useful utility for kernel development, to the point that practically we couldn't do without it any more, and it isn't merged into the kernel. It's a separate project with a separate life, and it is *better* for it. The same goes for all the tools that everybody uses every day for kernel development, often without even thinking about them. So utility to kernel development is not a reason for merging it into the kernel. NOT AT ALL. *Please* don't try to harm useful code just for the heck of it. Again, total *bullshit*. Right now, the whole attach the kvmtool to the kernel as a remora doesn't make any sense at all, and not merging it doesn't harm anything AT ALL. Quite the reverse. The fact that kvmtool isn't available as a standalone project probably keeps people actively from using it. You can't just fetch kvmtool. You have to fetch the kernel and kvmtool, and if you're a kernel developer you either have to make a whole new kernel tree for it (which is stupid) or merge it into your normal kernel tree that has development that has nothing to do with kvmtool (which is stupid AND F*CKING INSANE) Please stop this silliness, IMO it's not constructive at all ... Ingo, it's not us being silly, it is *you*. What the heck is the advantage of merging it into the kernel? It has never ever been explained. This is not like perf, where there wasn't any alternatives, and oprofile had shown over many many years that the situation wasn't improving: it was only getting worse, and more disconnected from the actual capabilities of the hardware. But kvmtool is no perf. There are other virtual boxes, and rather than being limited, they are more capable! The selling tool of kvmtool was never that it did something particularly magical, it was always that it did less, and was easier to use. But that does not in any way mean should be merged. You can do less and be easier to use and stand on your own legs. So here, let me state it very very clearly: I will not be merging kvmtool. It's not about useful code. It's not about the project keeping to improve. Both of those would seem to be *better* outside the kernel, where there isn't that artificial and actually harmful tie-in. In other words, I don't see *any* advantage to merging kvmtool. I think merging it would be an active mistake, and would just tie two projects together that just shouldn't be tied together. So nobody is hurting useful code, except perhaps you. Explain to me why I'm wrong. I don't think you can. You certainly haven't so far. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 active mistake, and would just tie two projects together that just shouldn't be tied together. The two are already tied together - that was the whole premise of the project! What Ingo proposed two years ago was to implement a (simple) userspace counterpart of KVM under tools/kvm using kernel development process and reusing kernel code as much as possible. He predicted that we'd eventually have: - a clean codebase that's accessible to new developers - new kernel features developed in 'lock-step' with the userspace code - encouraged kernel developers to write userspace code As it turns out, Ingo's predictions were correct. We support KVM on ARMv8 even before the in-kernel code has hit mainline. People implemented vhost drivers in lock-step. Most of the contributors are also kernel developers. And we in fact have a clean codebase that's accessible to anyone who knows the kernel coding style. I honestly don't see any of these things happening had we not taken the path suggested by Ingo early on. On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds torva...@linux-foundation.org wrote: The fact that kvmtool isn't available as a standalone project probably keeps people actively from using it. You can't just fetch kvmtool. You have to fetch the kernel and kvmtool, and if you're a kernel developer you either have to make a whole new kernel tree for it (which is stupid) or merge it into your normal kernel tree that has development that has nothing to do with kvmtool (which is stupid AND F*CKING INSANE) Actually, as a kernel developer, you don't need to do that. You can 'make install' from a kvmtool branch and leave it at that - just like with perf. [ And if it was in your tree, you'd wouldn't even need the branch ;-). ] 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. On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds torva...@linux-foundation.org wrote: git is a hell of a lot more useful utility for kernel development, to the point that practically we couldn't do without it any more, and it isn't merged into the kernel. It's a separate project with a separate life, and it is *better* for it. Sure but the difference between git and kvmtool is that a significant chuck of kvmtool development is directly related to in-kernel KVM and device drivers. That's why I've argued from day one that tools/kvm is 'special'. Pekka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 userspace code. Quite frankly, that's just optimizing for the wrong case. The merged case seems to make sense for you and Ingo, and nobody else. And then you wonder why nobody else wants to merge it. I've told you my reasons, you didn't give me *any* actual reasons for me to merge the code. NONE of your statements made any sense at all, since everything you talk about could have been done with a separate project. The only thing the lock-step does is to generate the kind of dependency that I ABSOLUTELY DETEST, where one version of kvmtools goes along with one version of the kernel. That's a huge disadvantage (and we've actually seen signs of that in the perf tool too, where old versions of the tools have been broken, because the people working on them have been way too much in lock-step with the kernel it is used on). And if it's not the case that they have to be used in lockstep, then clearly kvmtool developers could just as easily just have a separate git repository. So you can't have it both ways. What's so wrong with just making it a separate project? Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 has been submitted multiple times. Last October, after not accepting it for the v3.7 merge window, Linus said: "I have yet to see a compelling argument for merging it. It's tons of code, it doesnt match the original "small simple" model, and I think it would be better off as a separate project." -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpy80DwKydMR.pgp Description: PGP signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 to remove it from your tree, I just would like it removed from that branch that is included in linux-next (tip/auto-latest). I know others who also use it for testing. > Note that I never actually had any maintenance problems due to > it: it's orthogonal, and as long as you don't use it explicitly > (such as its 'make kvmconfig' feature - which is rather handy) > it never actually broke anything. I don't doubt any of that, it is just that Linus has explicitly said that he will not pull it into his tree. Thus, it should not be in linux-next. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLeyg2QyDLd.pgp Description: PGP signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 didn't ask you to remove it from your tree, I just would like it removed from that branch that is included in linux-next (tip/auto-latest). I know others who also use it for testing. Note that I never actually had any maintenance problems due to it: it's orthogonal, and as long as you don't use it explicitly (such as its 'make kvmconfig' feature - which is rather handy) it never actually broke anything. I don't doubt any of that, it is just that Linus has explicitly said that he will not pull it into his tree. Thus, it should not be in linux-next. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLeyg2QyDLd.pgp Description: PGP signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 v3.2. It has been submitted multiple times. Last October, after not accepting it for the v3.7 merge window, Linus said: I have yet to see a compelling argument for merging it. It's tons of code, it doesnt match the original small simple model, and I think it would be better off as a separate project. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpy80DwKydMR.pgp Description: PGP signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 actually been meaning to get back to this, so, today I >> will drop the kvmtool tree and, Ingo, if you could (at your >> convenience i.e. when you are next rebasing it) remove it from >> tip/auto-latest, thanks. > > Pekka still intends to send it in the next merge window AFAIK, > and I use it for testing rather frequently so I'm not going to > remove it from my tree for the time being. > > Note that I never actually had any maintenance problems due to > it: it's orthogonal, and as long as you don't use it explicitly > (such as its 'make kvmconfig' feature - which is rather handy) > it never actually broke anything. > 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? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 kconfig > > > > treats it as a fatal error. > > > > > > Applied, thanks guys! > > > > Adding Stephen to the cc. > > > > What's the endgame for kvmtool/next? The patch that this fixes has been > > sitting in linux-next for over 15 months and hasn't been pulled by Linus, > > yet some find it to be quite useful. > > > > Is it a permanent addition to linux-next, is there a route to mainline, > > or something else? > > 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 actually been meaning to get back to this, so, today I > will drop the kvmtool tree and, Ingo, if you could (at your > convenience i.e. when you are next rebasing it) remove it from > tip/auto-latest, thanks. Pekka still intends to send it in the next merge window AFAIK, and I use it for testing rather frequently so I'm not going to remove it from my tree for the time being. Note that I never actually had any maintenance problems due to it: it's orthogonal, and as long as you don't use it explicitly (such as its 'make kvmconfig' feature - which is rather handy) it never actually broke anything. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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. > > > > Applied, thanks guys! > > Adding Stephen to the cc. > > What's the endgame for kvmtool/next? The patch that this fixes has been > sitting in linux-next for over 15 months and hasn't been pulled by Linus, > yet some find it to be quite useful. > > Is it a permanent addition to linux-next, is there a route to mainline, > or something else? 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 actually been meaning to get back to this, so, today I will drop the kvmtool tree and, Ingo, if you could (at your convenience i.e. when you are next rebasing it) remove it from tip/auto-latest, thanks. This does not, of course, rule out it being reinstated if Linus can be convinced. Nor does it make a judgement on the project itself, it is just because linux-next is meant to represent what is to be merged into Linus' tree in the next merge window. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpC9fQffUlXa.pgp Description: PGP signature
kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 error. Applied, thanks guys! Adding Stephen to the cc. What's the endgame for kvmtool/next? The patch that this fixes has been sitting in linux-next for over 15 months and hasn't been pulled by Linus, yet some find it to be quite useful. Is it a permanent addition to linux-next, is there a route to mainline, or something else? 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 actually been meaning to get back to this, so, today I will drop the kvmtool tree and, Ingo, if you could (at your convenience i.e. when you are next rebasing it) remove it from tip/auto-latest, thanks. This does not, of course, rule out it being reinstated if Linus can be convinced. Nor does it make a judgement on the project itself, it is just because linux-next is meant to represent what is to be merged into Linus' tree in the next merge window. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpC9fQffUlXa.pgp Description: PGP signature
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
* 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 merges - I don't think kconfig treats it as a fatal error. Applied, thanks guys! Adding Stephen to the cc. What's the endgame for kvmtool/next? The patch that this fixes has been sitting in linux-next for over 15 months and hasn't been pulled by Linus, yet some find it to be quite useful. Is it a permanent addition to linux-next, is there a route to mainline, or something else? 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 actually been meaning to get back to this, so, today I will drop the kvmtool tree and, Ingo, if you could (at your convenience i.e. when you are next rebasing it) remove it from tip/auto-latest, thanks. Pekka still intends to send it in the next merge window AFAIK, and I use it for testing rather frequently so I'm not going to remove it from my tree for the time being. Note that I never actually had any maintenance problems due to it: it's orthogonal, and as long as you don't use it explicitly (such as its 'make kvmconfig' feature - which is rather handy) it never actually broke anything. 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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
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 actually been meaning to get back to this, so, today I will drop the kvmtool tree and, Ingo, if you could (at your convenience i.e. when you are next rebasing it) remove it from tip/auto-latest, thanks. Pekka still intends to send it in the next merge window AFAIK, and I use it for testing rather frequently so I'm not going to remove it from my tree for the time being. Note that I never actually had any maintenance problems due to it: it's orthogonal, and as long as you don't use it explicitly (such as its 'make kvmconfig' feature - which is rather handy) it never actually broke anything. 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? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
