All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	"David S. Miller" <davem@davemloft.net>,
	sparclinux@vger.kernel.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev@ozlabs.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Greg Kroah-Hartman <gregkh@suse.de>,
	Lothar Wassmann <LW@KARO-electronics.de>,
	linux-usb@vger.kernel.org, Roland Dreier <rolandd@cisco.com>,
	Yevgeny Petrilin <yevgenyp@mellanox.co.il>,
	netdev@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	linux-ia64@vger.kernel.org, linux-altix@sgi.com
Subject: Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear,
Date: Tue, 13 Oct 2009 02:18:18 +0000	[thread overview]
Message-ID: <20091013021818.GA3898@localhost.localdomain> (raw)
In-Reply-To: <20091009164100.85a36188.akpm@linux-foundation.org>

On Fri, Oct 09, 2009 at 04:41:00PM -0700, Andrew Morton wrote:
> On Fri,  9 Oct 2009 17:29:15 +0900
> Akinobu Mita <akinobu.mita@gmail.com> wrote:
> 
> > This introduces new bitmap functions:
> > 
> > bitmap_set: Set specified bit area
> > bitmap_clear: Clear specified bit area
> > bitmap_find_next_zero_area: Find free bit area
> > 
> > These are stolen from iommu helper.
> > 
> > I changed the return value of bitmap_find_next_zero_area if there is
> > no zero area.
> > 
> > find_next_zero_area in iommu helper: returns -1
> > bitmap_find_next_zero_area: return >= bitmap size
> 
> I'll plan to merge this patch into 2.6.32 so we can trickle all the
> other patches into subsystems in an orderly fashion.

Sounds good.

> > +void bitmap_set(unsigned long *map, int i, int len)
> > +{
> > +	int end = i + len;
> > +
> > +	while (i < end) {
> > +		__set_bit(i, map);
> > +		i++;
> > +	}
> > +}
> 
> This is really inefficient, isn't it?  It's a pretty trivial matter to
> romp through memory 32 or 64 bits at a time.

OK. I'll do

> > +unsigned long bitmap_find_next_zero_area(unsigned long *map,
> > +					 unsigned long size,
> > +					 unsigned long start,
> > +					 unsigned int nr,
> > +					 unsigned long align_mask)
> > +{
> > +	unsigned long index, end, i;
> > +again:
> > +	index = find_next_zero_bit(map, size, start);
> > +
> > +	/* Align allocation */
> > +	index = (index + align_mask) & ~align_mask;
> > +
> > +	end = index + nr;
> > +	if (end >= size)
> > +		return end;
> > +	i = find_next_bit(map, end, index);
> > +	if (i < end) {
> > +		start = i + 1;
> > +		goto again;
> > +	}
> > +	return index;
> > +}
> > +EXPORT_SYMBOL(bitmap_find_next_zero_area);
> 
> This needs documentation, please.  It appears that `size' is the size
> of the bitmap and `nr' is the number of zeroed bits we're looking for,
> but an inattentive programmer could get those reversed.
> 
> Also the semantics of `align_mask' could benefit from spelling out.  Is
> the alignment with respect to memory boundaries or with respect to
> `map' or with respect to map+start or what?

OK. I will document it.

And I plan to change bitmap_find_next_zero_area() to take the alignment
instead of an align_mask as Roland said.

> And why does align_mask exist at all?  I was a bit surprised to see it
> there.  In which scenarios will it be non-zero?

Because the users of iommu-helper and mlx4 need the alignment requirement
for the zero area.

arch/powerpc/kernel/iommu.c
arch/x86/kernel/amd_iommu.c
arch/x86/kernel/pci-gart_64.c
drivers/net/mlx4/alloc.c


WARNING: multiple messages have this Message-ID (diff)
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	linux-ia64@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	x86@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-altix@sgi.com,
	Yevgeny Petrilin <yevgenyp@mellanox.co.il>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	linuxppc-dev@ozlabs.org, Ingo Molnar <mingo@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	linux-usb@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Lothar Wassmann <LW@KARO-electronics.de>
Subject: Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
Date: Tue, 13 Oct 2009 11:18:18 +0900	[thread overview]
Message-ID: <20091013021818.GA3898@localhost.localdomain> (raw)
In-Reply-To: <20091009164100.85a36188.akpm@linux-foundation.org>

On Fri, Oct 09, 2009 at 04:41:00PM -0700, Andrew Morton wrote:
> On Fri,  9 Oct 2009 17:29:15 +0900
> Akinobu Mita <akinobu.mita@gmail.com> wrote:
> 
> > This introduces new bitmap functions:
> > 
> > bitmap_set: Set specified bit area
> > bitmap_clear: Clear specified bit area
> > bitmap_find_next_zero_area: Find free bit area
> > 
> > These are stolen from iommu helper.
> > 
> > I changed the return value of bitmap_find_next_zero_area if there is
> > no zero area.
> > 
> > find_next_zero_area in iommu helper: returns -1
> > bitmap_find_next_zero_area: return >= bitmap size
> 
> I'll plan to merge this patch into 2.6.32 so we can trickle all the
> other patches into subsystems in an orderly fashion.

Sounds good.

> > +void bitmap_set(unsigned long *map, int i, int len)
> > +{
> > +	int end = i + len;
> > +
> > +	while (i < end) {
> > +		__set_bit(i, map);
> > +		i++;
> > +	}
> > +}
> 
> This is really inefficient, isn't it?  It's a pretty trivial matter to
> romp through memory 32 or 64 bits at a time.

OK. I'll do

> > +unsigned long bitmap_find_next_zero_area(unsigned long *map,
> > +					 unsigned long size,
> > +					 unsigned long start,
> > +					 unsigned int nr,
> > +					 unsigned long align_mask)
> > +{
> > +	unsigned long index, end, i;
> > +again:
> > +	index = find_next_zero_bit(map, size, start);
> > +
> > +	/* Align allocation */
> > +	index = (index + align_mask) & ~align_mask;
> > +
> > +	end = index + nr;
> > +	if (end >= size)
> > +		return end;
> > +	i = find_next_bit(map, end, index);
> > +	if (i < end) {
> > +		start = i + 1;
> > +		goto again;
> > +	}
> > +	return index;
> > +}
> > +EXPORT_SYMBOL(bitmap_find_next_zero_area);
> 
> This needs documentation, please.  It appears that `size' is the size
> of the bitmap and `nr' is the number of zeroed bits we're looking for,
> but an inattentive programmer could get those reversed.
> 
> Also the semantics of `align_mask' could benefit from spelling out.  Is
> the alignment with respect to memory boundaries or with respect to
> `map' or with respect to map+start or what?

OK. I will document it.

And I plan to change bitmap_find_next_zero_area() to take the alignment
instead of an align_mask as Roland said.

> And why does align_mask exist at all?  I was a bit surprised to see it
> there.  In which scenarios will it be non-zero?

Because the users of iommu-helper and mlx4 need the alignment requirement
for the zero area.

arch/powerpc/kernel/iommu.c
arch/x86/kernel/amd_iommu.c
arch/x86/kernel/pci-gart_64.c
drivers/net/mlx4/alloc.c

WARNING: multiple messages have this Message-ID (diff)
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	linux-ia64@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	x86@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-altix@sgi.com,
	Yevgeny Petrilin <yevgenyp@mellanox.co.il>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	linuxppc-dev@ozlabs.org, Ingo Molnar <mingo@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	linux-usb@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Lothar Wassmann <LW@KARO-electronics.de>
Subject: Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear,
Date: Tue, 13 Oct 2009 02:18:18 +0000	[thread overview]
Message-ID: <20091013021818.GA3898@localhost.localdomain> (raw)
In-Reply-To: <20091009164100.85a36188.akpm@linux-foundation.org>

On Fri, Oct 09, 2009 at 04:41:00PM -0700, Andrew Morton wrote:
> On Fri,  9 Oct 2009 17:29:15 +0900
> Akinobu Mita <akinobu.mita@gmail.com> wrote:
> 
> > This introduces new bitmap functions:
> > 
> > bitmap_set: Set specified bit area
> > bitmap_clear: Clear specified bit area
> > bitmap_find_next_zero_area: Find free bit area
> > 
> > These are stolen from iommu helper.
> > 
> > I changed the return value of bitmap_find_next_zero_area if there is
> > no zero area.
> > 
> > find_next_zero_area in iommu helper: returns -1
> > bitmap_find_next_zero_area: return >= bitmap size
> 
> I'll plan to merge this patch into 2.6.32 so we can trickle all the
> other patches into subsystems in an orderly fashion.

Sounds good.

> > +void bitmap_set(unsigned long *map, int i, int len)
> > +{
> > +	int end = i + len;
> > +
> > +	while (i < end) {
> > +		__set_bit(i, map);
> > +		i++;
> > +	}
> > +}
> 
> This is really inefficient, isn't it?  It's a pretty trivial matter to
> romp through memory 32 or 64 bits at a time.

OK. I'll do

> > +unsigned long bitmap_find_next_zero_area(unsigned long *map,
> > +					 unsigned long size,
> > +					 unsigned long start,
> > +					 unsigned int nr,
> > +					 unsigned long align_mask)
> > +{
> > +	unsigned long index, end, i;
> > +again:
> > +	index = find_next_zero_bit(map, size, start);
> > +
> > +	/* Align allocation */
> > +	index = (index + align_mask) & ~align_mask;
> > +
> > +	end = index + nr;
> > +	if (end >= size)
> > +		return end;
> > +	i = find_next_bit(map, end, index);
> > +	if (i < end) {
> > +		start = i + 1;
> > +		goto again;
> > +	}
> > +	return index;
> > +}
> > +EXPORT_SYMBOL(bitmap_find_next_zero_area);
> 
> This needs documentation, please.  It appears that `size' is the size
> of the bitmap and `nr' is the number of zeroed bits we're looking for,
> but an inattentive programmer could get those reversed.
> 
> Also the semantics of `align_mask' could benefit from spelling out.  Is
> the alignment with respect to memory boundaries or with respect to
> `map' or with respect to map+start or what?

OK. I will document it.

And I plan to change bitmap_find_next_zero_area() to take the alignment
instead of an align_mask as Roland said.

> And why does align_mask exist at all?  I was a bit surprised to see it
> there.  In which scenarios will it be non-zero?

Because the users of iommu-helper and mlx4 need the alignment requirement
for the zero area.

arch/powerpc/kernel/iommu.c
arch/x86/kernel/amd_iommu.c
arch/x86/kernel/pci-gart_64.c
drivers/net/mlx4/alloc.c


WARNING: multiple messages have this Message-ID (diff)
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	"David S. Miller" <davem@davemloft.net>,
	sparclinux@vger.kernel.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev@ozlabs.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Greg Kroah-Hartman <gregkh@suse.de>,
	Lothar Wassmann <LW@KARO-electronics.de>,
	linux-usb@vger.kernel.org, Roland Dreier <rolandd@cisco.com>,
	Yevgeny Petrilin <yevgenyp@mellanox.co.il>,
	netdev@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	linux-ia64@vger.kernel.org, linux-altix@sgi.com
Subject: Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
Date: Tue, 13 Oct 2009 11:18:18 +0900	[thread overview]
Message-ID: <20091013021818.GA3898@localhost.localdomain> (raw)
In-Reply-To: <20091009164100.85a36188.akpm@linux-foundation.org>

On Fri, Oct 09, 2009 at 04:41:00PM -0700, Andrew Morton wrote:
> On Fri,  9 Oct 2009 17:29:15 +0900
> Akinobu Mita <akinobu.mita@gmail.com> wrote:
> 
> > This introduces new bitmap functions:
> > 
> > bitmap_set: Set specified bit area
> > bitmap_clear: Clear specified bit area
> > bitmap_find_next_zero_area: Find free bit area
> > 
> > These are stolen from iommu helper.
> > 
> > I changed the return value of bitmap_find_next_zero_area if there is
> > no zero area.
> > 
> > find_next_zero_area in iommu helper: returns -1
> > bitmap_find_next_zero_area: return >= bitmap size
> 
> I'll plan to merge this patch into 2.6.32 so we can trickle all the
> other patches into subsystems in an orderly fashion.

Sounds good.

> > +void bitmap_set(unsigned long *map, int i, int len)
> > +{
> > +	int end = i + len;
> > +
> > +	while (i < end) {
> > +		__set_bit(i, map);
> > +		i++;
> > +	}
> > +}
> 
> This is really inefficient, isn't it?  It's a pretty trivial matter to
> romp through memory 32 or 64 bits at a time.

OK. I'll do

> > +unsigned long bitmap_find_next_zero_area(unsigned long *map,
> > +					 unsigned long size,
> > +					 unsigned long start,
> > +					 unsigned int nr,
> > +					 unsigned long align_mask)
> > +{
> > +	unsigned long index, end, i;
> > +again:
> > +	index = find_next_zero_bit(map, size, start);
> > +
> > +	/* Align allocation */
> > +	index = (index + align_mask) & ~align_mask;
> > +
> > +	end = index + nr;
> > +	if (end >= size)
> > +		return end;
> > +	i = find_next_bit(map, end, index);
> > +	if (i < end) {
> > +		start = i + 1;
> > +		goto again;
> > +	}
> > +	return index;
> > +}
> > +EXPORT_SYMBOL(bitmap_find_next_zero_area);
> 
> This needs documentation, please.  It appears that `size' is the size
> of the bitmap and `nr' is the number of zeroed bits we're looking for,
> but an inattentive programmer could get those reversed.
> 
> Also the semantics of `align_mask' could benefit from spelling out.  Is
> the alignment with respect to memory boundaries or with respect to
> `map' or with respect to map+start or what?

OK. I will document it.

And I plan to change bitmap_find_next_zero_area() to take the alignment
instead of an align_mask as Roland said.

> And why does align_mask exist at all?  I was a bit surprised to see it
> there.  In which scenarios will it be non-zero?

Because the users of iommu-helper and mlx4 need the alignment requirement
for the zero area.

arch/powerpc/kernel/iommu.c
arch/x86/kernel/amd_iommu.c
arch/x86/kernel/pci-gart_64.c
drivers/net/mlx4/alloc.c


  reply	other threads:[~2009-10-13  2:18 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-09  8:29 [PATCH 1/8] iommu-helper: Simplify find_next_zero_area Akinobu Mita
2009-10-09  8:29 ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-09  8:29   ` Akinobu Mita
2009-10-09  8:29   ` Akinobu Mita
2009-10-09  8:29   ` Akinobu Mita
2009-10-09  8:29   ` [PATCH 3/8] iommu-helper: Use bitmap library Akinobu Mita
2009-10-09  8:29     ` Akinobu Mita
2009-10-09  8:29     ` Akinobu Mita
2009-10-09  8:29     ` [PATCH 4/8] isp1362-hcd: Use bitmap_find_next_zero_area Akinobu Mita
2009-10-09  8:29       ` [PATCH 5/8] mlx4: " Akinobu Mita
2009-10-09  8:29         ` [PATCH 6/8] sparc: " Akinobu Mita
2009-10-09  8:29           ` Akinobu Mita
2009-10-09  8:29           ` [PATCH 7/8] ia64: " Akinobu Mita
2009-10-09  8:29             ` Akinobu Mita
2009-10-09  8:29             ` [PATCH 8/8] genalloc: " Akinobu Mita
2009-10-09  9:16           ` [PATCH 6/8] sparc: " David Miller
2009-10-09  9:16             ` David Miller
2009-10-09 23:41   ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Andrew Morton
2009-10-09 23:41     ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Andrew Morton
2009-10-09 23:41     ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Andrew Morton
2009-10-09 23:41     ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Andrew Morton
2009-10-13  2:18     ` Akinobu Mita [this message]
2009-10-13  2:18       ` Akinobu Mita
2009-10-13  2:18       ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-13  2:18       ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-13  9:10       ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-13  9:10         ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-13  9:10         ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-13  9:10         ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-13 21:54         ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Michael Ellerman
2009-10-13 21:54           ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Michael Ellerman
2009-10-13 21:54           ` Michael Ellerman
2009-10-13 21:54           ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Michael Ellerman
2009-10-13 21:54           ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Michael Ellerman
2009-10-14  3:39           ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-14  3:39             ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-14  3:39             ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-14  3:39             ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-14  3:22         ` [PATCH -mmotm] Fix Akinobu Mita
2009-10-14  3:22           ` [PATCH -mmotm] Fix bitmap-introduce-bitmap_set-bitmap_clear-bitmap_find_next_zero_area. patch Akinobu Mita
2009-10-14  3:22           ` [PATCH -mmotm] Fix Akinobu Mita
2009-10-14  3:22           ` [PATCH -mmotm] Fix bitmap-introduce-bitmap_set-bitmap_clear-bitmap_find_next_zero_area. patch Akinobu Mita
2009-10-15  6:07           ` [PATCH -mmotm -v2] Fix Akinobu Mita
2009-10-15  6:07             ` [PATCH -mmotm -v2] Fix bitmap-introduce-bitmap_set-bitmap_clear-bitmap_find_next_zero_area. patch Akinobu Mita
2009-10-15  6:07             ` [PATCH -mmotm -v2] Fix Akinobu Mita
2009-10-15  6:07             ` [PATCH -mmotm -v2] Fix bitmap-introduce-bitmap_set-bitmap_clear-bitmap_find_next_zero_area. patch Akinobu Mita
2009-10-17 13:43         ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, FUJITA Tomonori
2009-10-17 13:43           ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area FUJITA Tomonori
2009-10-17 13:43           ` FUJITA Tomonori
2009-10-17 13:43           ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, FUJITA Tomonori
2009-10-17 13:43           ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area FUJITA Tomonori
2009-10-17 14:43           ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-17 14:43             ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-17 14:43             ` Akinobu Mita
2009-10-17 14:43             ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-17 14:43             ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-17 14:51             ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, FUJITA Tomonori
2009-10-17 14:51               ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area FUJITA Tomonori
2009-10-17 14:51               ` FUJITA Tomonori
2009-10-17 14:51               ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, FUJITA Tomonori
2009-10-17 14:51               ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area FUJITA Tomonori
2009-10-17 15:42               ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-17 15:42                 ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita
2009-10-17 15:42                 ` Akinobu Mita
2009-10-17 15:42                 ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, Akinobu Mita
2009-10-17 15:42                 ` [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area Akinobu Mita

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=20091013021818.GA3898@localhost.localdomain \
    --to=akinobu.mita@gmail.com \
    --cc=LW@KARO-electronics.de \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=fenghua.yu@intel.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-altix@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=rolandd@cisco.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yevgenyp@mellanox.co.il \
    /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.