From: Rusty Russell <rusty@rustcorp.com.au>
To: James Morris <jmorris@namei.org>
Cc: lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@muc.de>, Andrew Morton <akpm@linux-foundation.org>,
virtualization <virtualization@lists.osdl.org>
Subject: Re: [PATCH 4 of 7] lguest: Config and headers
Date: Sat, 10 Feb 2007 10:41:55 +1100 [thread overview]
Message-ID: <1171064515.15356.10.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0702091304090.9927@d.namei>
On Fri, 2007-02-09 at 13:15 -0500, James Morris wrote:
> On Sat, 10 Feb 2007, Rusty Russell wrote:
>
> > +/* 64k ought to be enough for anybody! */
> > +#define HYPERVISOR_MAP_ORDER 16
> > +#define HYPERVISOR_PAGES ((1 << HYPERVISOR_MAP_ORDER)/PAGE_SIZE)
>
> I think it'd be better to go back to defining HYPERVISOR_SIZE then derive
> the map order from that via get_order(), as it should be 4 instead of 16;
> and this code is now both implying PAGE_SIZE while also using it for
> calculations.
Well it was the use of get_order() which triggered Andi's alarm bells,
so I went back to deriving it. This code is correct, however.
get_order() is one of those classic functions only a kernel coder could
love. Look how lovingly it has been optimized:
#define get_order(n) \
( \
__builtin_constant_p(n) ? \
((n < (1UL << PAGE_SHIFT)) ? 0 : ilog2(n) - PAGE_SHIFT) : \
__get_order(n, PAGE_SHIFT) \
)
All that time spent, yet no consideration that it should be called
"get_page_order()" or some name which hints that the divide by page size
is happening. It's even documented in the comment above, so someone
thought it needed explaining. Too bad they chose to explain it instead
of actually clarifying it. 8(
Cheers,
Rusty.
next prev parent reply other threads:[~2007-02-09 23:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-09 14:59 [PATCH 0 of 7] lguest host code Rusty Russell
2007-02-09 15:03 ` [PATCH 1 of 7] lguest: Move mce_disabled to asm/mce.h so lguest can use it Rusty Russell
2007-02-09 15:03 ` [PATCH 2 of 7] lguest: Rename cpu_gdt_descr and remove extern declaration from smpboot.c Rusty Russell
2007-02-09 15:04 ` [PATCH 3 of 7] lguest: Remove extern declaration from mm/discontig.c, put in header Rusty Russell
2007-02-09 15:09 ` [PATCH 4 of 7] lguest: Config and headers Rusty Russell
2007-02-09 15:14 ` [PATCH 5 of 7] lguest: the host code (lg.ko) Rusty Russell
2007-02-09 15:17 ` [PATCH 6 of 7] lguest: Guest code Rusty Russell
2007-02-09 15:21 ` [PATCH 7 of 7] lguest: Makefile Rusty Russell
2007-02-09 18:15 ` [PATCH 4 of 7] lguest: Config and headers James Morris
2007-02-09 23:41 ` Rusty Russell [this message]
2007-02-10 3:45 ` James Morris
2007-02-10 9:33 ` Rusty Russell
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=1171064515.15356.10.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=ak@muc.de \
--cc=akpm@linux-foundation.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.osdl.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox