From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Rafael Aquini <aquini@redhat.com> Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Rusty Russell <rusty@rustcorp.com.au>, "Michael S. Tsirkin" <mst@redhat.com>, Rik van Riel <riel@redhat.com> Subject: Re: [PATCH 1/4] mm: introduce compaction and migration for virtio ballooned pages Date: Wed, 27 Jun 2012 11:30:23 -0400 [thread overview] Message-ID: <20120627153023.GF17154@phenom.dumpdata.com> (raw) In-Reply-To: <20120627151716.GA3653@t510.redhat.com> On Wed, Jun 27, 2012 at 12:17:17PM -0300, Rafael Aquini wrote: > On Tue, Jun 26, 2012 at 07:57:55PM -0400, Konrad Rzeszutek Wilk wrote: > > > +#if defined(CONFIG_VIRTIO_BALLOON) || defined(CONFIG_VIRTIO_BALLOON_MODULE) .. snip.. > > > +struct address_space *balloon_mapping; > > > +EXPORT_SYMBOL(balloon_mapping); > > > > Why don't you call this kvm_balloon_mapping - and when other balloon > > drivers use it, then change it to something more generic. Also at that > > future point the other balloon drivers might do it a bit differently so > > it might be that will be reworked completly. > > Ok, I see your point. However I really think it's better to keep the naming as > generic as possible today and, in the future, those who need to change it a bit can > do it with no pain at all. I believe this way we potentially prevent unnecessary code > duplication, as it will just be a matter of adjusting those preprocessor checking to > include other balloon driver to the scheme, or get rid of all of them (in case all > balloon drivers assume the very same technique for their page mobility primitives). Either way, if a driver is going to use this, they would need to adjust the preprocessor checking (as you pointed out) to include: #ifdef CONFIG_HYPERVISORX_BALLOON in this file. At which point they might as well rename the exported symbol to be more generic - and do whatever else they need to do (add extra stuff maybe?). > > As I can be utterly wrong on this, lets see if other folks raise the same > concerns about this naming scheme I'm using here. If it ends up being a general > concern that it would be better not being generic at this point, I'll happily > switch my approach to whatever comes up to be the most feasible way of doing it. My point here is that its more of name-space pollution. I've gotten flak on doing this with drivers - which had very generic sounding names, and it made more sense to rename them with a proper prefix. You are adding pieces of code for the benefit of one driver. But that (getting flak on the namespace) might be because the mailing list where I had posted had more aggressive reviewers and this one is composed of more mellow folks who are OK with this. Andrew is the final man - and I am not sure what he prefers.
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: Rafael Aquini <aquini@redhat.com> Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Rusty Russell <rusty@rustcorp.com.au>, "Michael S. Tsirkin" <mst@redhat.com>, Rik van Riel <riel@redhat.com> Subject: Re: [PATCH 1/4] mm: introduce compaction and migration for virtio ballooned pages Date: Wed, 27 Jun 2012 11:30:23 -0400 [thread overview] Message-ID: <20120627153023.GF17154@phenom.dumpdata.com> (raw) In-Reply-To: <20120627151716.GA3653@t510.redhat.com> On Wed, Jun 27, 2012 at 12:17:17PM -0300, Rafael Aquini wrote: > On Tue, Jun 26, 2012 at 07:57:55PM -0400, Konrad Rzeszutek Wilk wrote: > > > +#if defined(CONFIG_VIRTIO_BALLOON) || defined(CONFIG_VIRTIO_BALLOON_MODULE) .. snip.. > > > +struct address_space *balloon_mapping; > > > +EXPORT_SYMBOL(balloon_mapping); > > > > Why don't you call this kvm_balloon_mapping - and when other balloon > > drivers use it, then change it to something more generic. Also at that > > future point the other balloon drivers might do it a bit differently so > > it might be that will be reworked completly. > > Ok, I see your point. However I really think it's better to keep the naming as > generic as possible today and, in the future, those who need to change it a bit can > do it with no pain at all. I believe this way we potentially prevent unnecessary code > duplication, as it will just be a matter of adjusting those preprocessor checking to > include other balloon driver to the scheme, or get rid of all of them (in case all > balloon drivers assume the very same technique for their page mobility primitives). Either way, if a driver is going to use this, they would need to adjust the preprocessor checking (as you pointed out) to include: #ifdef CONFIG_HYPERVISORX_BALLOON in this file. At which point they might as well rename the exported symbol to be more generic - and do whatever else they need to do (add extra stuff maybe?). > > As I can be utterly wrong on this, lets see if other folks raise the same > concerns about this naming scheme I'm using here. If it ends up being a general > concern that it would be better not being generic at this point, I'll happily > switch my approach to whatever comes up to be the most feasible way of doing it. My point here is that its more of name-space pollution. I've gotten flak on doing this with drivers - which had very generic sounding names, and it made more sense to rename them with a proper prefix. You are adding pieces of code for the benefit of one driver. But that (getting flak on the namespace) might be because the mailing list where I had posted had more aggressive reviewers and this one is composed of more mellow folks who are OK with this. Andrew is the final man - and I am not sure what he prefers. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-06-27 15:39 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-06-25 23:25 [PATCH 0/4] make balloon pages movable by compaction Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini 2012-06-25 23:25 ` [PATCH 1/4] mm: introduce compaction and migration for virtio ballooned pages Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini 2012-06-25 23:31 ` Konrad Rzeszutek Wilk 2012-06-25 23:31 ` Konrad Rzeszutek Wilk 2012-06-25 23:31 ` Konrad Rzeszutek Wilk 2012-06-25 23:57 ` Rafael Aquini 2012-06-25 23:57 ` Rafael Aquini 2012-06-25 23:57 ` Rafael Aquini 2012-06-26 10:17 ` Mel Gorman 2012-06-26 10:17 ` Mel Gorman 2012-06-26 16:52 ` Andi Kleen 2012-06-26 16:52 ` Andi Kleen 2012-06-26 16:54 ` Andi Kleen 2012-06-26 16:54 ` Andi Kleen 2012-06-26 16:54 ` Andi Kleen 2012-06-26 20:15 ` Mel Gorman 2012-06-26 20:15 ` Mel Gorman 2012-06-26 20:34 ` Andi Kleen 2012-06-26 20:34 ` Andi Kleen 2012-06-26 20:34 ` Andi Kleen 2012-06-27 9:42 ` Mel Gorman 2012-06-27 9:42 ` Mel Gorman 2012-06-27 9:42 ` Mel Gorman 2012-06-26 20:15 ` Mel Gorman 2012-06-26 16:52 ` Andi Kleen 2012-06-26 22:01 ` Rafael Aquini 2012-06-26 22:01 ` Rafael Aquini 2012-06-26 22:01 ` Rafael Aquini 2012-06-26 10:17 ` Mel Gorman 2012-06-26 13:17 ` Rik van Riel 2012-06-26 13:17 ` Rik van Riel 2012-06-26 13:17 ` Rik van Riel 2012-06-26 13:20 ` Mel Gorman 2012-06-26 13:20 ` Mel Gorman 2012-06-26 13:20 ` Mel Gorman 2012-06-26 23:57 ` Konrad Rzeszutek Wilk 2012-06-26 23:57 ` Konrad Rzeszutek Wilk 2012-06-27 15:17 ` Rafael Aquini 2012-06-27 15:17 ` Rafael Aquini 2012-06-27 15:30 ` Konrad Rzeszutek Wilk [this message] 2012-06-27 15:30 ` Konrad Rzeszutek Wilk 2012-06-27 15:30 ` Konrad Rzeszutek Wilk 2012-06-27 15:17 ` Rafael Aquini 2012-06-26 23:57 ` Konrad Rzeszutek Wilk 2012-06-25 23:25 ` [PATCH 2/4] virtio_balloon: handle concurrent accesses to virtio_balloon struct elements Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini 2012-06-25 23:25 ` [PATCH 3/4] virtio_balloon: introduce migration primitives to balloon pages Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini 2012-06-25 23:25 ` [PATCH 4/4] mm: add vm event counters for balloon pages compaction Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini 2012-06-25 23:25 ` Rafael Aquini
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20120627153023.GF17154@phenom.dumpdata.com \ --to=konrad.wilk@oracle.com \ --cc=aquini@redhat.com \ --cc=konrad@darnok.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mst@redhat.com \ --cc=riel@redhat.com \ --cc=rusty@rustcorp.com.au \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.