All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Akinobu Mita <akinobu.mita@gmail.com>
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: Fri, 09 Oct 2009 23:41:00 +0000	[thread overview]
Message-ID: <20091009164100.85a36188.akpm@linux-foundation.org> (raw)
In-Reply-To: <1255076961-21325-2-git-send-email-akinobu.mita@gmail.com>

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.

> +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.

> +EXPORT_SYMBOL(bitmap_set);
> +
> +void bitmap_clear(unsigned long *map, int start, int nr)
> +{
> +	int end = start + nr;
> +
> +	while (start < end) {
> +		__clear_bit(start, map);
> +		start++;
> +	}
> +}
> +EXPORT_SYMBOL(bitmap_clear);

Ditto.

> +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?

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?


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Akinobu Mita <akinobu.mita@gmail.com>
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: Fri, 9 Oct 2009 16:41:00 -0700	[thread overview]
Message-ID: <20091009164100.85a36188.akpm@linux-foundation.org> (raw)
In-Reply-To: <1255076961-21325-2-git-send-email-akinobu.mita@gmail.com>

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.

> +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.

> +EXPORT_SYMBOL(bitmap_set);
> +
> +void bitmap_clear(unsigned long *map, int start, int nr)
> +{
> +	int end = start + nr;
> +
> +	while (start < end) {
> +		__clear_bit(start, map);
> +		start++;
> +	}
> +}
> +EXPORT_SYMBOL(bitmap_clear);

Ditto.

> +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?

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?

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Akinobu Mita <akinobu.mita@gmail.com>
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: Fri, 09 Oct 2009 23:41:00 +0000	[thread overview]
Message-ID: <20091009164100.85a36188.akpm@linux-foundation.org> (raw)
In-Reply-To: <1255076961-21325-2-git-send-email-akinobu.mita@gmail.com>

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.

> +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.

> +EXPORT_SYMBOL(bitmap_set);
> +
> +void bitmap_clear(unsigned long *map, int start, int nr)
> +{
> +	int end = start + nr;
> +
> +	while (start < end) {
> +		__clear_bit(start, map);
> +		start++;
> +	}
> +}
> +EXPORT_SYMBOL(bitmap_clear);

Ditto.

> +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?

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?


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Akinobu Mita <akinobu.mita@gmail.com>
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: Fri, 9 Oct 2009 16:41:00 -0700	[thread overview]
Message-ID: <20091009164100.85a36188.akpm@linux-foundation.org> (raw)
In-Reply-To: <1255076961-21325-2-git-send-email-akinobu.mita@gmail.com>

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.

> +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.

> +EXPORT_SYMBOL(bitmap_set);
> +
> +void bitmap_clear(unsigned long *map, int start, int nr)
> +{
> +	int end = start + nr;
> +
> +	while (start < end) {
> +		__clear_bit(start, map);
> +		start++;
> +	}
> +}
> +EXPORT_SYMBOL(bitmap_clear);

Ditto.

> +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?

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?


  parent reply	other threads:[~2009-10-09 23:41 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   ` Andrew Morton [this message]
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     ` [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  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=20091009164100.85a36188.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=LW@KARO-electronics.de \
    --cc=akinobu.mita@gmail.com \
    --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.