From: Andrew Morton <akpm@linux-foundation.org>
To: Fengguang Wu <fengguang.wu@gmail.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
Rusty Russell <rusty@rustcorp.com.au>,
Dave Jones <davej@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel <linux-kernel@vger.kernel.org>,
riel <riel@redhat.com>, Tim Pepper <lnxninja@us.ibm.com>,
Chris Snook <csnook@redhat.com>,
Jens Axboe <jens.axboe@oracle.com>,
linux-ext4@vger.kernel.org, Mingming Cao <cmm@us.ibm.com>,
Bjorn Helgaas <bjorn.helgaas@hp.com>,
Chris Ahna <christopher.j.ahna@intel.com>,
David Mosberger-Tang <davidm@hpl.hp.com>,
Kyle McMartin <kyle@parisc-linux.org>,
Dave Jones <davej@codemonkey.org.uk>,
Dave Airlie <airlied@linux.ie>
Subject: Re: [PATCH 0/3] readahead drop behind and size adjustment
Date: Mon, 23 Jul 2007 18:17:01 -0700 [thread overview]
Message-ID: <20070723181701.c5551449.akpm@linux-foundation.org> (raw)
In-Reply-To: <385238729.01475@ustc.edu.cn>
On Tue, 24 Jul 2007 08:47:28 +0800
Fengguang Wu <fengguang.wu@gmail.com> wrote:
> Subject: convert ill defined log2() to ilog2()
>
> It's *wrong* to have
> #define log2(n) ffz(~(n))
> It should be *reversed*:
> #define log2(n) flz(~(n))
> or
> #define log2(n) fls(n)
> or just use
> ilog2(n) defined in linux/log2.h.
>
> This patch follows the last solution, recommended by Andrew Morton.
>
> //Or are they simply the wrong naming, and is in fact correct in behavior?
>
> Cc: linux-ext4@vger.kernel.org
> Cc: Mingming Cao <cmm@us.ibm.com>
> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Cc: Chris Ahna <christopher.j.ahna@intel.com>
> Cc: David Mosberger-Tang <davidm@hpl.hp.com>
> Cc: Kyle McMartin <kyle@parisc-linux.org>
> Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
> ---
> drivers/char/agp/hp-agp.c | 9 +++------
> drivers/char/agp/i460-agp.c | 5 ++---
> drivers/char/agp/parisc-agp.c | 7 ++-----
> fs/ext4/super.c | 6 ++----
> 4 files changed, 9 insertions(+), 18 deletions(-)
hm, yes, there is a risk that the code was accidentally correct. Or the
code has only ever dealt with power-of-2 inputs, in which case it happens
to work either way.
David(s) and ext4-people: could we please have a close review of these
changes?
Thanks.
> --- linux-2.6.22-rc6-mm1.orig/drivers/char/agp/hp-agp.c
> +++ linux-2.6.22-rc6-mm1/drivers/char/agp/hp-agp.c
> @@ -14,15 +14,12 @@
> #include <linux/pci.h>
> #include <linux/init.h>
> #include <linux/agp_backend.h>
> +#include <linux/log2.h>
>
> #include <asm/acpi-ext.h>
>
> #include "agp.h"
>
> -#ifndef log2
> -#define log2(x) ffz(~(x))
> -#endif
> -
> #define HP_ZX1_IOC_OFFSET 0x1000 /* ACPI reports SBA, we want IOC */
>
> /* HP ZX1 IOC registers */
> @@ -256,7 +253,7 @@ hp_zx1_configure (void)
> readl(hp->ioc_regs+HP_ZX1_IMASK);
> writel(hp->iova_base|1, hp->ioc_regs+HP_ZX1_IBASE);
> readl(hp->ioc_regs+HP_ZX1_IBASE);
> - writel(hp->iova_base|log2(HP_ZX1_IOVA_SIZE), hp->ioc_regs+HP_ZX1_PCOM);
> + writel(hp->iova_base|ilog2(HP_ZX1_IOVA_SIZE), hp->ioc_regs+HP_ZX1_PCOM);
> readl(hp->ioc_regs+HP_ZX1_PCOM);
> }
>
> @@ -284,7 +281,7 @@ hp_zx1_tlbflush (struct agp_memory *mem)
> {
> struct _hp_private *hp = &hp_private;
>
> - writeq(hp->gart_base | log2(hp->gart_size), hp->ioc_regs+HP_ZX1_PCOM);
> + writeq(hp->gart_base | ilog2(hp->gart_size), hp->ioc_regs+HP_ZX1_PCOM);
> readq(hp->ioc_regs+HP_ZX1_PCOM);
> }
>
> --- linux-2.6.22-rc6-mm1.orig/drivers/char/agp/i460-agp.c
> +++ linux-2.6.22-rc6-mm1/drivers/char/agp/i460-agp.c
> @@ -13,6 +13,7 @@
> #include <linux/string.h>
> #include <linux/slab.h>
> #include <linux/agp_backend.h>
> +#include <linux/log2.h>
>
> #include "agp.h"
>
> @@ -59,8 +60,6 @@
> */
> #define WR_FLUSH_GATT(index) RD_GATT(index)
>
> -#define log2(x) ffz(~(x))
> -
> static struct {
> void *gatt; /* ioremap'd GATT area */
>
> @@ -148,7 +147,7 @@ static int i460_fetch_size (void)
> * values[i].size.
> */
> values[i].num_entries = (values[i].size << 8) >> (I460_IO_PAGE_SHIFT - 12);
> - values[i].page_order = log2((sizeof(u32)*values[i].num_entries) >> PAGE_SHIFT);
> + values[i].page_order = ilog2((sizeof(u32)*values[i].num_entries) >> PAGE_SHIFT);
> }
>
> for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {
> --- linux-2.6.22-rc6-mm1.orig/drivers/char/agp/parisc-agp.c
> +++ linux-2.6.22-rc6-mm1/drivers/char/agp/parisc-agp.c
> @@ -18,6 +18,7 @@
> #include <linux/init.h>
> #include <linux/klist.h>
> #include <linux/agp_backend.h>
> +#include <linux/log2.h>
>
> #include <asm-parisc/parisc-device.h>
> #include <asm-parisc/ropes.h>
> @@ -27,10 +28,6 @@
> #define DRVNAME "quicksilver"
> #define DRVPFX DRVNAME ": "
>
> -#ifndef log2
> -#define log2(x) ffz(~(x))
> -#endif
> -
> #define AGP8X_MODE_BIT 3
> #define AGP8X_MODE (1 << AGP8X_MODE_BIT)
>
> @@ -92,7 +89,7 @@ parisc_agp_tlbflush(struct agp_memory *m
> {
> struct _parisc_agp_info *info = &parisc_agp_info;
>
> - writeq(info->gart_base | log2(info->gart_size), info->ioc_regs+IOC_PCOM);
> + writeq(info->gart_base | ilog2(info->gart_size), info->ioc_regs+IOC_PCOM);
> readq(info->ioc_regs+IOC_PCOM); /* flush */
> }
>
> --- linux-2.6.22-rc6-mm1.orig/fs/ext4/super.c
> +++ linux-2.6.22-rc6-mm1/fs/ext4/super.c
> @@ -1433,8 +1433,6 @@ static void ext4_orphan_cleanup (struct
> sb->s_flags = s_flags; /* Restore MS_RDONLY status */
> }
>
> -#define log2(n) ffz(~(n))
> -
> /*
> * Maximal file size. There is a direct, and {,double-,triple-}indirect
> * block limit, and also a limit of (2^32 - 1) 512-byte sectors in i_blocks.
> @@ -1706,8 +1704,8 @@ static int ext4_fill_super (struct super
> sbi->s_desc_per_block = blocksize / EXT4_DESC_SIZE(sb);
> sbi->s_sbh = bh;
> sbi->s_mount_state = le16_to_cpu(es->s_state);
> - sbi->s_addr_per_block_bits = log2(EXT4_ADDR_PER_BLOCK(sb));
> - sbi->s_desc_per_block_bits = log2(EXT4_DESC_PER_BLOCK(sb));
> + sbi->s_addr_per_block_bits = ilog2(EXT4_ADDR_PER_BLOCK(sb));
> + sbi->s_desc_per_block_bits = ilog2(EXT4_DESC_PER_BLOCK(sb));
> for (i=0; i < 4; i++)
> sbi->s_hash_seed[i] = le32_to_cpu(es->s_hash_seed[i]);
> sbi->s_def_hash_version = es->s_def_hash_version;
next prev parent reply other threads:[~2007-07-24 1:18 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-21 21:00 [PATCH 0/3] readahead drop behind and size adjustment Peter Zijlstra
2007-07-21 21:00 ` [PATCH 1/3] readahead: drop behind Peter Zijlstra
2007-07-21 20:29 ` Eric St-Laurent
2007-07-21 20:37 ` Peter Zijlstra
2007-07-21 20:59 ` Eric St-Laurent
2007-07-21 21:06 ` Peter Zijlstra
2007-07-25 3:55 ` Eric St-Laurent
2007-07-21 21:00 ` [PATCH 2/3] readahead: fadvise drop behind controls Peter Zijlstra
2007-07-21 21:00 ` [PATCH 3/3] readahead: scale max readahead size depending on memory size Peter Zijlstra
2007-07-22 8:24 ` Jens Axboe
2007-07-22 8:36 ` Peter Zijlstra
2007-07-22 8:50 ` Jens Axboe
2007-07-22 9:17 ` Peter Zijlstra
2007-07-22 16:44 ` Jens Axboe
2007-07-23 10:04 ` Jörn Engel
2007-07-23 10:11 ` Jens Axboe
2007-07-23 22:44 ` Rusty Russell
2007-07-22 23:52 ` Rik van Riel
2007-07-23 5:22 ` Jens Axboe
2007-07-22 8:45 ` Fengguang Wu
2007-07-22 8:45 ` Fengguang Wu
2007-07-22 8:59 ` Peter Zijlstra
2007-07-22 9:53 ` Fengguang Wu
2007-07-22 9:53 ` Fengguang Wu
2007-07-22 2:39 ` [PATCH 0/3] readahead drop behind and size adjustment Fengguang Wu
2007-07-22 2:39 ` Fengguang Wu
2007-07-22 2:44 ` Dave Jones
2007-07-22 8:10 ` Fengguang Wu
2007-07-22 8:10 ` Fengguang Wu
2007-07-22 8:24 ` Peter Zijlstra
2007-07-22 8:29 ` Fengguang Wu
2007-07-22 8:29 ` Fengguang Wu
2007-07-22 8:33 ` Rusty Russell
2007-07-22 8:45 ` Peter Zijlstra
2007-07-23 9:00 ` Nick Piggin
2007-07-23 14:24 ` Fengguang Wu
2007-07-23 14:24 ` Fengguang Wu
2007-07-23 19:40 ` Andrew Morton
2007-07-24 0:47 ` Fengguang Wu
2007-07-24 0:47 ` Fengguang Wu
2007-07-24 1:17 ` Andrew Morton [this message]
2007-07-24 8:50 ` Andreas Dilger
2007-07-24 4:30 ` Nick Piggin
2007-07-25 4:35 ` Eric St-Laurent
2007-07-25 5:19 ` Nick Piggin
2007-07-25 6:18 ` Eric St-Laurent
2007-07-25 7:09 ` Nick Piggin
2007-07-25 7:48 ` Eric St-Laurent
2007-07-25 15:36 ` Rik van Riel
2007-07-25 15:33 ` Rik van Riel
2007-07-29 7:44 ` Eric St-Laurent
2007-07-25 15:28 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2007-07-22 11:11 Al Boldi
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=20070723181701.c5551449.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=airlied@linux.ie \
--cc=bjorn.helgaas@hp.com \
--cc=christopher.j.ahna@intel.com \
--cc=cmm@us.ibm.com \
--cc=csnook@redhat.com \
--cc=davej@codemonkey.org.uk \
--cc=davej@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=fengguang.wu@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=kyle@parisc-linux.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lnxninja@us.ibm.com \
--cc=nickpiggin@yahoo.com.au \
--cc=riel@redhat.com \
--cc=rusty@rustcorp.com.au \
/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 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.