From: Ulf Magnusson <ulfalizer@gmail.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Rich Felker <dalias@libc.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
X86 ML <x86@kernel.org>, Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux <sparclinux@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Jonathan Corbet <corbet@lwn.net>,
Richard Weinberger <richard@nod.at>,
Linux-sh list <linux-sh@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, Emese Revfy <re.emese@gmail.com>,
Kees Cook <keescook@chromium.org>,
uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Peter Oberparleiter <oberpar@linux.vnet.ibm.com>,
Jeff Dike <jdike@addtoit.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
user-mode-linux-user@lists.sourceforge.net,
Thomas Gleixner <tglx@linutronix.de>,
Michal Marek <michal.lkml@markovi.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
Date: Wed, 21 Feb 2018 21:39:46 +0000 [thread overview]
Message-ID: <20180221213946.w4v6ywy7fbiy6oyc@huvuddator> (raw)
In-Reply-To: <CAK7LNAR3OMh9Q9ZfaBq=FpSJ-+DT5-RH_20ohV-iu34pX9hFKw@mail.gmail.com>
On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
> > <yamada.masahiro@socionext.com> wrote:
> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
> >>> <yamada.masahiro@socionext.com> wrote:
> >>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> >>
> >> Let me clarify my concern.
> >>
> >> When we test the compiler flag, is there a case
> >> where a particular flag depends on -m{32,64} ?
> >>
> >> For example, is there a compiler that supports -fstack-protector
> >> for 64bit mode, but unsupports it for 32bit mode?
> >>
> >> $(cc-option -m32) -> y
> >> $(cc-option -m64) -> y
> >> $(cc-option -fstack-protector) -> y
> >> $(cc-option -m32 -fstack-protector) -> n
> >> $(cc-option -m64 -fstack-protector) -> y
> >>
> >> I guess this is unlikely to happen,
> >> but I am not whether it is zero possibility.
> >>
> >> If this could happen,
> >> $(cc-option ) must be evaluated together with
> >> correct bi-arch option (either -m32 or -m64).
> >>
> >>
> >> Currently, -m32/-m64 is specified in Makefile,
> >> but we are moving compiler tests to Kconfig
> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
> >
> > I don't think it can happen for this particular combination (stack protector
> > and word size), but I'm sure we'll eventually run into options that
> > need to be tested in combination. For the current CFLAGS_KERNEL
> > setting, we definitely have the case of needing the variables to be
> > evaluated in a specific order.
> >
>
>
>
>
> I was thinking of how we can handle complex cases
> in the current approach.
>
>
>
> (Case 1)
>
> Compiler flag -foo and -bar interacts, so
> we also need to check the combination of the two.
>
>
> config CC_HAS_FOO
> def_bool $(cc-option -foo)
>
> config CC_HAS_BAR
> def_bool $(cc-option -bar)
>
> config CC_HAS_FOO_WITH_BAR
> def_bool $(cc-option -foo -bar)
>
>
>
> (Case 2)
> Compiler flag -foo is sensitive to word-size.
> So, we need to test this option together with -m32/-m64.
> User can toggle CONFIG_64BIT, like i386/x86_64.
>
>
> config CC_NEEDS_M64
> def_bool $(cc-option -m64) && 64BIT
>
> config CC_NEEDS_M32
> def_bool $(cc-option -m32) && !64BIT
>
> config CC_HAS_FOO
> bool
> default $(cc-option -m64 -foo) if CC_NEEDS_M64
> default $(cc-option -m32 -foo) if CC_NEEDS_M32
> default $(cc-option -foo)
>
>
>
> (Case 3)
> Compiler flag -foo is sensitive to endian-ness.
>
>
> config CC_NEEDS_BIG_ENDIAN
> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
>
> config CC_NEEDS_LITTLE_ENDIAN
> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
>
> config CC_HAS_FOO
> bool
> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
> default $(cc-option -mlittle-endian -foo) if CC_NEEDS_LITTLE_ENDIAN
> default $(cc-option -foo)
>
>
>
>
> Hmm, I think I can implement those somehow.
> But, I hope we do not have many instances like this...
>
>
> If you know more naive cases, please share your knowledge.
>
> Thanks!
>
>
> --
> Best Regards
> Masahiro Yamada
Would get pretty bad if a test needs to consider multiple symbols.
Exponential explosion there...
I thought some more about the implementation of dynamic (post-parsing)
functions to see how bad it would get with the current implementation.
Some background on how things work now:
1. All expression operands in Kconfig are symbols.
2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
you symbols with those strings as names and S_UNKNOWN type (because
they act like references to undefined symbols).
3. For "foo-$(fn foo)", you also get a symbol with that string as its
name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
4. Symbols with S_UNKNOWN type get their name as their string value,
and the tristate value n.
So, if you do string expansion on the names of symbols with S_UNKNOWN
type in sym_calc_value(), you're almost there with the current
implementation, except for the tristate case.
Maybe you could set the tristate value of S_UNKNOWN symbols depending on
the string value you end up with. Things are getting pretty confusing at
that point.
Could have something like S_DYNAMIC as well. More Kconfig complexity...
Then there's other complications:
1. SYMBOL_CONST is no longer constant.
2. Dependency loop detection needs to consider symbol references
within strings.
3. Dependency loop detection relies on static knowledge of what
symbols a symbol depends on. That might get messy for certain
expansions, though it might be things you wouldn't do in practice.
4. Symbols still need to be properly invalidated. It looks like at
least menuconfig just does a dumb invalidate-everything whenever
the value of a symbol is changed though, so it might not require
extra work. (Bit messier in Kconfiglib, which does minimal
invalidation to keep scripts fast, but just need to extract a few
extra deps there.)
It looks like dynamic functions could get quite messy, but might be
doable if absolutely required. There's probably more devils in the
details though.
I don't think the static function model precludes switching models later
btw, when people have more experience.
Cheers,
Ulf
WARNING: multiple messages have this Message-ID (diff)
From: Ulf Magnusson <ulfalizer@gmail.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Rich Felker <dalias@libc.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
X86 ML <x86@kernel.org>, Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux <sparclinux@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Jonathan Corbet <corbet@lwn.net>,
Richard Weinberger <richard@nod.at>,
Linux-sh list <linux-sh@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, Emese Revfy <re.emese@gmail.com>,
Kees Cook <keescook@chromium.org>,
uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Peter Oberparleiter <oberpar@linux.vnet.ibm.com>,
Jeff Dike <jdike@addtoit.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
user-mode-linux-user@lists.sourceforge.net,
Thomas Gleixner <tglx@linutronix.de>,
Michal Marek <michal.lkml@markovi.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
Date: Wed, 21 Feb 2018 22:39:46 +0100 [thread overview]
Message-ID: <20180221213946.w4v6ywy7fbiy6oyc@huvuddator> (raw)
In-Reply-To: <CAK7LNAR3OMh9Q9ZfaBq=FpSJ-+DT5-RH_20ohV-iu34pX9hFKw@mail.gmail.com>
On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
> > <yamada.masahiro@socionext.com> wrote:
> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
> >>> <yamada.masahiro@socionext.com> wrote:
> >>>> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson <ulfalizer@gmail.com>:
> >>
> >> Let me clarify my concern.
> >>
> >> When we test the compiler flag, is there a case
> >> where a particular flag depends on -m{32,64} ?
> >>
> >> For example, is there a compiler that supports -fstack-protector
> >> for 64bit mode, but unsupports it for 32bit mode?
> >>
> >> $(cc-option -m32) -> y
> >> $(cc-option -m64) -> y
> >> $(cc-option -fstack-protector) -> y
> >> $(cc-option -m32 -fstack-protector) -> n
> >> $(cc-option -m64 -fstack-protector) -> y
> >>
> >> I guess this is unlikely to happen,
> >> but I am not whether it is zero possibility.
> >>
> >> If this could happen,
> >> $(cc-option ) must be evaluated together with
> >> correct bi-arch option (either -m32 or -m64).
> >>
> >>
> >> Currently, -m32/-m64 is specified in Makefile,
> >> but we are moving compiler tests to Kconfig
> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
> >
> > I don't think it can happen for this particular combination (stack protector
> > and word size), but I'm sure we'll eventually run into options that
> > need to be tested in combination. For the current CFLAGS_KERNEL
> > setting, we definitely have the case of needing the variables to be
> > evaluated in a specific order.
> >
>
>
>
>
> I was thinking of how we can handle complex cases
> in the current approach.
>
>
>
> (Case 1)
>
> Compiler flag -foo and -bar interacts, so
> we also need to check the combination of the two.
>
>
> config CC_HAS_FOO
> def_bool $(cc-option -foo)
>
> config CC_HAS_BAR
> def_bool $(cc-option -bar)
>
> config CC_HAS_FOO_WITH_BAR
> def_bool $(cc-option -foo -bar)
>
>
>
> (Case 2)
> Compiler flag -foo is sensitive to word-size.
> So, we need to test this option together with -m32/-m64.
> User can toggle CONFIG_64BIT, like i386/x86_64.
>
>
> config CC_NEEDS_M64
> def_bool $(cc-option -m64) && 64BIT
>
> config CC_NEEDS_M32
> def_bool $(cc-option -m32) && !64BIT
>
> config CC_HAS_FOO
> bool
> default $(cc-option -m64 -foo) if CC_NEEDS_M64
> default $(cc-option -m32 -foo) if CC_NEEDS_M32
> default $(cc-option -foo)
>
>
>
> (Case 3)
> Compiler flag -foo is sensitive to endian-ness.
>
>
> config CC_NEEDS_BIG_ENDIAN
> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
>
> config CC_NEEDS_LITTLE_ENDIAN
> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
>
> config CC_HAS_FOO
> bool
> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
> default $(cc-option -mlittle-endian -foo) if CC_NEEDS_LITTLE_ENDIAN
> default $(cc-option -foo)
>
>
>
>
> Hmm, I think I can implement those somehow.
> But, I hope we do not have many instances like this...
>
>
> If you know more naive cases, please share your knowledge.
>
> Thanks!
>
>
> --
> Best Regards
> Masahiro Yamada
Would get pretty bad if a test needs to consider multiple symbols.
Exponential explosion there...
I thought some more about the implementation of dynamic (post-parsing)
functions to see how bad it would get with the current implementation.
Some background on how things work now:
1. All expression operands in Kconfig are symbols.
2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
you symbols with those strings as names and S_UNKNOWN type (because
they act like references to undefined symbols).
3. For "foo-$(fn foo)", you also get a symbol with that string as its
name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
4. Symbols with S_UNKNOWN type get their name as their string value,
and the tristate value n.
So, if you do string expansion on the names of symbols with S_UNKNOWN
type in sym_calc_value(), you're almost there with the current
implementation, except for the tristate case.
Maybe you could set the tristate value of S_UNKNOWN symbols depending on
the string value you end up with. Things are getting pretty confusing at
that point.
Could have something like S_DYNAMIC as well. More Kconfig complexity...
Then there's other complications:
1. SYMBOL_CONST is no longer constant.
2. Dependency loop detection needs to consider symbol references
within strings.
3. Dependency loop detection relies on static knowledge of what
symbols a symbol depends on. That might get messy for certain
expansions, though it might be things you wouldn't do in practice.
4. Symbols still need to be properly invalidated. It looks like at
least menuconfig just does a dumb invalidate-everything whenever
the value of a symbol is changed though, so it might not require
extra work. (Bit messier in Kconfiglib, which does minimal
invalidation to keep scripts fast, but just need to extract a few
extra deps there.)
It looks like dynamic functions could get quite messy, but might be
doable if absolutely required. There's probably more devils in the
details though.
I don't think the static function model precludes switching models later
btw, when people have more experience.
Cheers,
Ulf
next prev parent reply other threads:[~2018-02-21 21:39 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-16 18:38 [PATCH 00/23] kconfig: move compiler capability tests to Kconfig Masahiro Yamada
2018-02-16 18:38 ` Masahiro Yamada
2018-02-16 18:38 ` [PATCH 01/23] kbuild: remove kbuild cache Masahiro Yamada
2018-02-16 18:38 ` [PATCH 02/23] kbuild: remove CONFIG_CROSS_COMPILE support Masahiro Yamada
2018-02-16 18:38 ` [PATCH 03/23] kconfig: add xstrdup() helper Masahiro Yamada
2018-03-01 15:02 ` Masahiro Yamada
2018-02-16 18:38 ` [PATCH 04/23] kconfig: set SYMBOL_AUTO to the symbol marked with defconfig_list Masahiro Yamada
2018-03-01 15:05 ` Masahiro Yamada
2018-03-01 17:11 ` Ulf Magnusson
2018-02-16 18:38 ` [PATCH 05/23] kconfig: move and rename sym_expand_string_value() Masahiro Yamada
2018-02-16 18:38 ` [PATCH 06/23] kconfig: reference environments directly and remove 'option env=' syntax Masahiro Yamada
2018-02-16 18:38 ` Masahiro Yamada
2018-02-18 11:15 ` Ulf Magnusson
2018-02-18 11:15 ` Ulf Magnusson
2018-02-16 18:38 ` [PATCH 07/23] kconfig: add function support and implement 'shell' function Masahiro Yamada
2018-02-17 16:16 ` Ulf Magnusson
2018-02-19 15:57 ` Masahiro Yamada
2018-02-19 17:50 ` Ulf Magnusson
2018-02-19 20:06 ` Ulf Magnusson
2018-02-19 22:06 ` Ulf Magnusson
2018-02-16 18:38 ` [PATCH 08/23] kconfig: add 'macro' keyword to support user-defined function Masahiro Yamada
2018-02-16 19:49 ` Nicolas Pitre
2018-02-16 23:51 ` Ulf Magnusson
2018-02-17 2:30 ` Nicolas Pitre
2018-02-17 4:29 ` Ulf Magnusson
2018-02-17 4:44 ` Nicolas Pitre
2018-02-17 6:06 ` Ulf Magnusson
2018-02-16 18:38 ` [PATCH 09/23] kconfig: add 'cc-option' macro Masahiro Yamada
2018-02-16 18:38 ` [PATCH 10/23] stack-protector: test compiler capability in Kconfig and drop AUTO mode Masahiro Yamada
2018-02-21 4:39 ` Masahiro Yamada
2018-02-16 18:38 ` [PATCH 11/23] kconfig: add 'shell-stdout' function Masahiro Yamada
2018-02-16 19:17 ` Linus Torvalds
2018-02-19 4:48 ` Ulf Magnusson
2018-02-19 17:44 ` Linus Torvalds
2018-02-19 18:01 ` Linus Torvalds
2018-02-19 18:54 ` Ulf Magnusson
2018-02-21 4:59 ` Masahiro Yamada
2018-02-21 16:41 ` Ulf Magnusson
2018-02-21 17:01 ` Linus Torvalds
2018-02-16 18:38 ` [PATCH 12/23] kconfig: replace $UNAME_RELEASE with function call Masahiro Yamada
2018-02-16 18:38 ` [PATCH 13/23] kconfig: expand environments/functions in (main)menu, comment, prompt Masahiro Yamada
2018-02-16 18:38 ` [PATCH 14/23] kconfig: show compiler version text in the top comment Masahiro Yamada
2018-02-16 18:38 ` [PATCH 15/23] kconfig: add CC_IS_GCC and GCC_VERSION Masahiro Yamada
2018-02-16 18:38 ` [PATCH 16/23] kbuild: add clang-version.sh Masahiro Yamada
2018-02-16 18:38 ` [PATCH 17/23] kconfig: add CC_IS_CLANG and CLANG_VERSION Masahiro Yamada
2018-02-16 18:38 ` [PATCH 18/23] gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT Masahiro Yamada
2018-02-16 18:38 ` [PATCH 19/23] kcov: imply GCC_PLUGINS and GCC_PLUGIN_SANCOV instead of select'ing them Masahiro Yamada
2018-02-16 18:38 ` [PATCH 20/23] gcc-plugins: always build plugins with C++ Masahiro Yamada
2018-02-22 18:45 ` Emese Revfy
2018-02-22 18:45 ` Emese Revfy
2018-02-23 12:37 ` Masahiro Yamada
2018-02-16 18:38 ` [PATCH 21/23] gcc-plugins: move GCC version check for PowerPC to Kconfig Masahiro Yamada
2018-02-22 5:04 ` Andrew Donnellan
2018-02-16 18:38 ` [PATCH 22/23] gcc-plugins: test GCC plugin support in Kconfig Masahiro Yamada
2018-02-16 18:38 ` [PATCH 23/23] gcc-plugins: enable GCC_PLUGINS for COMPILE_TEST Masahiro Yamada
2018-02-18 22:13 ` [PATCH 00/23] kconfig: move compiler capability tests to Kconfig Sam Ravnborg
2018-02-18 22:13 ` Sam Ravnborg
2018-02-19 15:18 ` Ulf Magnusson
2018-02-19 15:18 ` Ulf Magnusson
2018-02-21 7:38 ` Masahiro Yamada
2018-02-21 7:38 ` Masahiro Yamada
2018-02-21 9:56 ` Arnd Bergmann
2018-02-21 9:56 ` Arnd Bergmann
2018-02-21 10:20 ` Masahiro Yamada
2018-02-21 10:20 ` Masahiro Yamada
2018-02-21 10:52 ` Arnd Bergmann
2018-02-21 10:52 ` Arnd Bergmann
2018-02-21 12:57 ` Masahiro Yamada
2018-02-21 12:57 ` Masahiro Yamada
2018-02-21 16:03 ` Arnd Bergmann
2018-02-21 16:03 ` Arnd Bergmann
2018-02-21 21:39 ` Ulf Magnusson [this message]
2018-02-21 21:39 ` Ulf Magnusson
2018-03-02 5:50 ` Masahiro Yamada
2018-03-02 5:50 ` Masahiro Yamada
2018-03-02 5:50 ` Masahiro Yamada
2018-03-02 9:03 ` Ulf Magnusson
2018-03-02 9:03 ` Ulf Magnusson
2018-03-02 9:03 ` Ulf Magnusson
2018-03-02 9:12 ` Ulf Magnusson
2018-03-02 9:12 ` Ulf Magnusson
2018-03-02 9:12 ` Ulf Magnusson
2018-02-22 3:22 ` Michael Ellerman
2018-02-22 3:22 ` Michael Ellerman
2018-02-22 3:22 ` Michael Ellerman
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=20180221213946.w4v6ywy7fbiy6oyc@huvuddator \
--to=ulfalizer@gmail.com \
--cc=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jdike@addtoit.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=michal.lkml@markovi.net \
--cc=mingo@redhat.com \
--cc=oberpar@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=rdunlap@infradead.org \
--cc=re.emese@gmail.com \
--cc=richard@nod.at \
--cc=sam@ravnborg.org \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=user-mode-linux-user@lists.sourceforge.net \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
--cc=ysato@users.sourceforge.jp \
/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.