From: Luis Chamberlain <mcgrof@kernel.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christoph Hellwig <hch@lst.de>, Brendan Higgins <brendanhiggins@google.com>, Cristina Moraru <cristina.moraru09@gmail.com>, "vegard.nossum@gmail.com" <vegard.nossum@gmail.com>, Valentin Rothberg <valentinrothberg@gmail.com>, Hannes Reinecke <hare@suse.de>, Sam Ravnborg <sam@ravnborg.org>, Michal Marek <mmarek@suse.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Tom Gundersen <teg@jklm.no>, Kay Sievers <kay@vrfy.org>, Rusty Russell <rusty@rustcorp.com.au>, Andrew Morton <akpm@linux-foundation.org>, backports@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>, "rafael.j.wysocki" <rafael.j.wysocki@intel.com>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, Takashi Iwai <tiwai@suse.de>, Mauro Carvalho Chehab <mchehab@osg.samsung.com>, Johannes Berg <johannes@sipsolutions.net>, Hauke Mehrtens <hauke@hauke-m.de>, Paul Bolle <pebolle@tiscali.nl>, Paul Gortmaker <paul.gortmaker@windriver.com>, Alexey Khoroshilov <khoroshilov@ispras.ru>, Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>, "Martin K. Petersen" <martin.petersen@oracle.com>, Laurence Oberman <loberman@redhat.com>, Johannes Thumshirn <jthumshirn@suse.de>, Tejun Heo <tj@kernel.org>, Jej B <James.Bottomley@hansenpartnership.com>, Theodore Ts'o <tytso@mit.edu>, Daniel Jonsson <danijons@student.chalmers.se>, Andrzej Wasowski <wasowski@itu.dk> Subject: Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Date: Wed, 3 Jul 2019 16:50:20 +0000 [thread overview] Message-ID: <20190703165020.GV19023@42.do-not-panic.com> (raw) In-Reply-To: <20190703074048.GH3033@kroah.com> On Wed, Jul 03, 2019 at 09:40:48AM +0200, Greg Kroah-Hartman wrote: > On Tue, Jul 02, 2019 at 08:51:06PM +0000, Luis Chamberlain wrote: > > On Sat, Jun 29, 2019 at 10:42:57AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Jun 28, 2019 at 11:40:22AM -0700, Luis Chamberlain wrote: > > > > On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig <hch@lst.de> wrote: > > > > > > > > > > On Wed, Jun 26, 2019 at 03:21:08PM -0700, Luis Chamberlain wrote: > > > > > > On Tue, Feb 5, 2019 at 2:07 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > > > > In lieu of no Luke Skywalker, if you will, for a large kconfig revamp > > > > > > > on this, I'm inclined to believe *at least* having some kconfig_symb > > > > > > > exposed for some modules is better than nothing. Christoph are you > > > > > > > totally opposed to this effort until we get a non-reverse engineered > > > > > > > effort in place? It just seems like an extraordinary amount of work > > > > > > > and I'm not quite sure who's volunteering to do it. > > > > > > > > > > > > > > Other stakeholders may benefit from at least having some config --> > > > > > > > module mapping for now. Not just backports or building slimmer > > > > > > > kernels. > > > > > > > > > > > > Christoph, *poke* > > > > > > > > > > Yes, I'm still totally opposed to a half-backed hack like this. > > > > > > > > The solution puts forward a mechanism to add a kconfig_symb where we > > > > are 100% certain we have a direct module --> config mapping. > > > > > > > > This is *currently* determined when the streamline_config.pl finds > > > > that an object has only *one* associated config symbol associated. As > > > > Cristina noted, of 62 modules on a running system 58 of them ended up > > > > getting the kconfig_symb assigned, that is 93.5% of all modules on the > > > > system being tested. For the other modules, if they did want this > > > > association, we could allow a way for modules to define their own > > > > KBUILD_KCONF variable so that this could be considered as well, or > > > > they can look at their own kconfig stuff to try to fit the model that > > > > does work. To be clear, the heuristics *can* be updated if there is > > > > confidence in alternative methods for resolution. But since it is > > > > reflective of our current situation, I cannot consider it a hack. > > > > > > > > This implementation is a reflection of our reality in the kernel, and > > > > as has been discussed in this thread, if we want to correct the gaps > > > > we need to do a lot of work. And *no one* is working towards these > > > > goals. > > > > > > > > That said, even if you go forward with an intrusive solution like the > > > > one you proposed we could still use the same kconfig_symb... > > > > > > > > So no, I don't see this as a hack. It's a reflection as to our current > > > > reality. And I cannot see how the kconfig_symb can lie or be > > > > incorrect. So in fact I think that pushing this forward also makes the > > > > problem statement clearer for the future of what semantics needs to be > > > > addressed, and helps us even annotate the problematic areas of the > > > > kernel. > > > > > > > > What negative aspects do you see with this being merged in practice? > > > > > > I'm trying to see what the actual problem that you are wanting to solve > > > here with this. What exactly is it? > > > > The problem is that there is no current maping of a module to respective > > kconfig symbol. > > That's because it is not just "one" symbol per module. This is true. But it is not the case for all modules. In fact it seems its true that most modules do have *one* main symbol. On at least Cristina's system of of 62 modules 58 *did* have one symbol. For the modules evaluated where this was not the case, it did seem wise to actually revise the symbol definition for the other modules. > If it were, you can just parse the Makefiles and get that single config > option for most modules, right? The heuristic essentially does this and only provides the module attribute where this was true. > But even then, multiple options can > influence a single module as to what actually gets built into that > module. Yes. For example one hardware device driver may support different families of chipsets, and so it could have sub-options for each family. > So, I would say, "who really cares"? For most visible modules it would seem we do have a one config symbol mapping which could enable it. And I noted who would care. The defaults of a module, for instance sub-options to enable / disable different support for different chipsets, *should* suffice for most users. > > > Who needs to determine the > > > "singular" configuration option that caused a kernel module to be built > > > at the expense of all other options? > > > > Folks wanting to slim down their kernel build, and users of backports. > > People who want to "slim" down things are rare, It is basic math though: Users of 'make localmodconfig' + backport users > Users of 'make localmodconfig' And yet we already support 'make localmodconfig'. So what is being proposed can help enhance 'make localmodconfig' and yet provides more users outside of those users, without requiring kernel sources. > and it's usually worth > it to work backwards anyway (see what functionality is needed and then > go from there, not look at the modules themselves). Or use a tool like > 'make localmodconfig' and trim. And I am noting we can further enhance a feature which we already do support, and enable *more* users requiring similar information. > > > What can that be used for and who will use it? > > > > Without a mapping there is no clean way to let you slim down your kernel > > using a distro kernel as a base, enabling only those things you really > > need. > > It's hard to determine "what you really need" :) Right, but at least for device functionality, the above would help significantly. It also poses the question whether or not device drivers *should* strive towards having one kconfig symbol to help with this. There is a lot of research over the lack of proper semantics on use of kconfig, and issues this causes. It is so bad that some researchers have tried define our semantics through *reverse engineering*. The question of whether or not we *should* strive to have *one* symbol per a driver for an actual hardware component is worth evaluating long term, for the sake of helping with semantics of kconfig use. I see there being gains with this, and I find it hard to find counters to where quite the opposite is true. Can you? > Use localmodconfig and you have a great start, then prune from there. This thread poses the question if we can do better, and suggests one small area where we can start. > Trying to put _all_ configuration dependencies in a single module isn't > going to work, our configuration language does not distill down to that. The question we should be evaluating if we *should* strive to buckle up on this and have at least one config symbol per module associated with hardware. I'm suggesting there are gains for this, and am providing two groups of users that would benefit from this clearly. And I'm also suggesting that it could help with kconfig semantics, long term. Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in
WARNING: multiple messages have this Message-ID (diff)
From: Luis Chamberlain <mcgrof@kernel.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christoph Hellwig <hch@lst.de>, Brendan Higgins <brendanhiggins@google.com>, Cristina Moraru <cristina.moraru09@gmail.com>, "vegard.nossum@gmail.com" <vegard.nossum@gmail.com>, Valentin Rothberg <valentinrothberg@gmail.com>, Hannes Reinecke <hare@suse.de>, Sam Ravnborg <sam@ravnborg.org>, Michal Marek <mmarek@suse.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Tom Gundersen <teg@jklm.no>, Kay Sievers <kay@vrfy.org>, Rusty Russell <rusty@rustcorp.com.au>, Andrew Morton <akpm@linux-foundation.org>, backports@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>, "rafael.j.wysocki" <rafael.j.wysocki@intel.com>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, Takashi Iwai <tiwai@suse.de>, Mauro Carvalho Chehab <mchehab@osg.samsung.com>, Johannes Berg <johannes@sipsolutions.net>, Hauke Mehrtens <hauke@hauke-m.de>, Paul Bolle <pebolle@tiscali.nl>, Paul Gortmaker <paul.gortmaker@windriver.com>, Alexey Khoroshilov <khoroshilov@ispras.ru>, Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>, "Martin K. Petersen" <martin.petersen@oracle.com>, Laurence Oberman <loberman@redhat.com>, Johannes Thumshirn <jthumshirn@suse.de>, Tejun Heo <tj@kernel.org>, Jej B <James.Bottomley@hansenpartnership.com>, Theodore Ts'o <tytso@mit.edu>, Daniel Jonsson <danijons@student.chalmers.se>, Andrzej Wasowski <wasowski@itu.dk> Subject: Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Date: Wed, 3 Jul 2019 16:50:20 +0000 [thread overview] Message-ID: <20190703165020.GV19023@42.do-not-panic.com> (raw) In-Reply-To: <20190703074048.GH3033@kroah.com> On Wed, Jul 03, 2019 at 09:40:48AM +0200, Greg Kroah-Hartman wrote: > On Tue, Jul 02, 2019 at 08:51:06PM +0000, Luis Chamberlain wrote: > > On Sat, Jun 29, 2019 at 10:42:57AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Jun 28, 2019 at 11:40:22AM -0700, Luis Chamberlain wrote: > > > > On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig <hch@lst.de> wrote: > > > > > > > > > > On Wed, Jun 26, 2019 at 03:21:08PM -0700, Luis Chamberlain wrote: > > > > > > On Tue, Feb 5, 2019 at 2:07 PM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > > > > In lieu of no Luke Skywalker, if you will, for a large kconfig revamp > > > > > > > on this, I'm inclined to believe *at least* having some kconfig_symb > > > > > > > exposed for some modules is better than nothing. Christoph are you > > > > > > > totally opposed to this effort until we get a non-reverse engineered > > > > > > > effort in place? It just seems like an extraordinary amount of work > > > > > > > and I'm not quite sure who's volunteering to do it. > > > > > > > > > > > > > > Other stakeholders may benefit from at least having some config --> > > > > > > > module mapping for now. Not just backports or building slimmer > > > > > > > kernels. > > > > > > > > > > > > Christoph, *poke* > > > > > > > > > > Yes, I'm still totally opposed to a half-backed hack like this. > > > > > > > > The solution puts forward a mechanism to add a kconfig_symb where we > > > > are 100% certain we have a direct module --> config mapping. > > > > > > > > This is *currently* determined when the streamline_config.pl finds > > > > that an object has only *one* associated config symbol associated. As > > > > Cristina noted, of 62 modules on a running system 58 of them ended up > > > > getting the kconfig_symb assigned, that is 93.5% of all modules on the > > > > system being tested. For the other modules, if they did want this > > > > association, we could allow a way for modules to define their own > > > > KBUILD_KCONF variable so that this could be considered as well, or > > > > they can look at their own kconfig stuff to try to fit the model that > > > > does work. To be clear, the heuristics *can* be updated if there is > > > > confidence in alternative methods for resolution. But since it is > > > > reflective of our current situation, I cannot consider it a hack. > > > > > > > > This implementation is a reflection of our reality in the kernel, and > > > > as has been discussed in this thread, if we want to correct the gaps > > > > we need to do a lot of work. And *no one* is working towards these > > > > goals. > > > > > > > > That said, even if you go forward with an intrusive solution like the > > > > one you proposed we could still use the same kconfig_symb... > > > > > > > > So no, I don't see this as a hack. It's a reflection as to our current > > > > reality. And I cannot see how the kconfig_symb can lie or be > > > > incorrect. So in fact I think that pushing this forward also makes the > > > > problem statement clearer for the future of what semantics needs to be > > > > addressed, and helps us even annotate the problematic areas of the > > > > kernel. > > > > > > > > What negative aspects do you see with this being merged in practice? > > > > > > I'm trying to see what the actual problem that you are wanting to solve > > > here with this. What exactly is it? > > > > The problem is that there is no current maping of a module to respective > > kconfig symbol. > > That's because it is not just "one" symbol per module. This is true. But it is not the case for all modules. In fact it seems its true that most modules do have *one* main symbol. On at least Cristina's system of of 62 modules 58 *did* have one symbol. For the modules evaluated where this was not the case, it did seem wise to actually revise the symbol definition for the other modules. > If it were, you can just parse the Makefiles and get that single config > option for most modules, right? The heuristic essentially does this and only provides the module attribute where this was true. > But even then, multiple options can > influence a single module as to what actually gets built into that > module. Yes. For example one hardware device driver may support different families of chipsets, and so it could have sub-options for each family. > So, I would say, "who really cares"? For most visible modules it would seem we do have a one config symbol mapping which could enable it. And I noted who would care. The defaults of a module, for instance sub-options to enable / disable different support for different chipsets, *should* suffice for most users. > > > Who needs to determine the > > > "singular" configuration option that caused a kernel module to be built > > > at the expense of all other options? > > > > Folks wanting to slim down their kernel build, and users of backports. > > People who want to "slim" down things are rare, It is basic math though: Users of 'make localmodconfig' + backport users > Users of 'make localmodconfig' And yet we already support 'make localmodconfig'. So what is being proposed can help enhance 'make localmodconfig' and yet provides more users outside of those users, without requiring kernel sources. > and it's usually worth > it to work backwards anyway (see what functionality is needed and then > go from there, not look at the modules themselves). Or use a tool like > 'make localmodconfig' and trim. And I am noting we can further enhance a feature which we already do support, and enable *more* users requiring similar information. > > > What can that be used for and who will use it? > > > > Without a mapping there is no clean way to let you slim down your kernel > > using a distro kernel as a base, enabling only those things you really > > need. > > It's hard to determine "what you really need" :) Right, but at least for device functionality, the above would help significantly. It also poses the question whether or not device drivers *should* strive towards having one kconfig symbol to help with this. There is a lot of research over the lack of proper semantics on use of kconfig, and issues this causes. It is so bad that some researchers have tried define our semantics through *reverse engineering*. The question of whether or not we *should* strive to have *one* symbol per a driver for an actual hardware component is worth evaluating long term, for the sake of helping with semantics of kconfig use. I see there being gains with this, and I find it hard to find counters to where quite the opposite is true. Can you? > Use localmodconfig and you have a great start, then prune from there. This thread poses the question if we can do better, and suggests one small area where we can start. > Trying to put _all_ configuration dependencies in a single module isn't > going to work, our configuration language does not distill down to that. The question we should be evaluating if we *should* strive to buckle up on this and have at least one config symbol per module associated with hardware. I'm suggesting there are gains for this, and am providing two groups of users that would benefit from this clearly. And I'm also suggesting that it could help with kconfig semantics, long term. Luis
next prev parent reply other threads:[~2019-07-03 16:50 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-17 19:26 [RFC PATCH 0/5] Add CONFIG symbol as module attribute Cristina Moraru 2016-08-17 19:26 ` [RFC PATCH 1/5] Add generation of Module.symb in streamline_config Cristina Moraru 2016-08-18 18:22 ` Luis R. Rodriguez 2016-08-18 18:22 ` Luis R. Rodriguez 2016-08-18 18:32 ` Luis R. Rodriguez 2016-08-18 18:32 ` Luis R. Rodriguez [not found] ` <CAGZ2q2xi9Uy-ye387=mWhy_fOEJBC593Nos7fH027m-_ZdoOXA@mail.gmail.com> 2016-08-20 14:49 ` Cristina-Gabriela Moraru 2016-08-20 14:49 ` Cristina-Gabriela Moraru 2016-08-23 19:00 ` Luis R. Rodriguez 2016-08-23 19:00 ` Luis R. Rodriguez 2016-08-17 19:27 ` [RFC PATCH 2/5] Add CONFIG symbol to module as compilation parameter Cristina Moraru 2016-08-18 18:10 ` Luis R. Rodriguez 2016-08-18 18:10 ` Luis R. Rodriguez 2016-08-18 18:55 ` Luis R. Rodriguez 2016-08-18 18:55 ` Luis R. Rodriguez 2016-08-20 15:11 ` Cristina-Gabriela Moraru 2016-08-20 15:11 ` Cristina-Gabriela Moraru 2016-08-23 19:07 ` Luis R. Rodriguez 2016-08-23 19:07 ` Luis R. Rodriguez 2016-08-17 19:27 ` [RFC PATCH 3/5] Trigger Module.ksymb generation in Makefile Cristina Moraru 2016-08-18 18:30 ` Luis R. Rodriguez 2016-08-18 18:30 ` Luis R. Rodriguez 2016-08-17 19:27 ` [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb module attribute Cristina Moraru 2016-08-18 18:59 ` Luis R. Rodriguez 2016-08-18 18:59 ` Luis R. Rodriguez 2016-08-20 15:16 ` Cristina-Gabriela Moraru 2016-08-20 15:16 ` Cristina-Gabriela Moraru 2016-08-23 19:10 ` Luis R. Rodriguez 2016-08-23 19:10 ` Luis R. Rodriguez 2016-08-17 19:27 ` [RFC PATCH 5/5] Add kconf_symb as kernel " Cristina Moraru 2016-08-18 19:02 ` Luis R. Rodriguez 2016-08-18 19:02 ` Luis R. Rodriguez 2016-08-18 17:55 ` [RFC PATCH 0/5] Add CONFIG symbol as " Luis R. Rodriguez 2016-08-18 17:55 ` Luis R. Rodriguez 2016-08-19 9:07 ` Michal Marek 2016-08-19 9:07 ` Michal Marek 2016-08-22 19:48 ` Cristina-Gabriela Moraru 2016-08-22 19:48 ` Cristina-Gabriela Moraru 2016-08-23 21:32 ` Luis R. Rodriguez 2016-08-23 21:32 ` Luis R. Rodriguez 2016-08-24 11:05 ` Michal Marek 2016-08-24 11:05 ` Michal Marek 2016-08-24 16:33 ` Luis R. Rodriguez 2016-08-24 16:33 ` Luis R. Rodriguez 2016-08-24 17:31 ` Naveen Kumar 2016-08-24 17:31 ` Naveen Kumar 2016-08-22 19:35 ` Cristina-Gabriela Moraru 2016-08-22 19:35 ` Cristina-Gabriela Moraru 2016-08-23 19:17 ` Luis R. Rodriguez 2016-08-23 19:17 ` Luis R. Rodriguez 2016-08-25 7:43 ` Christoph Hellwig 2016-08-25 7:43 ` Christoph Hellwig 2016-08-25 8:00 ` Johannes Berg 2016-08-25 8:00 ` Johannes Berg 2016-08-25 19:51 ` Luis R. Rodriguez 2016-08-25 19:51 ` Luis R. Rodriguez 2016-08-25 8:41 ` Michal Marek 2016-08-25 8:41 ` Michal Marek 2016-08-25 20:19 ` Luis R. Rodriguez 2016-08-25 20:19 ` Luis R. Rodriguez 2019-02-05 22:07 ` Luis Chamberlain 2019-02-05 22:07 ` Luis Chamberlain 2019-06-26 22:21 ` Luis Chamberlain 2019-06-26 22:21 ` Luis Chamberlain 2019-06-27 4:50 ` Christoph Hellwig 2019-06-27 4:50 ` Christoph Hellwig 2019-06-28 18:40 ` Luis Chamberlain 2019-06-28 18:40 ` Luis Chamberlain 2019-06-29 8:42 ` Greg Kroah-Hartman 2019-06-29 8:42 ` Greg Kroah-Hartman 2019-07-02 20:51 ` Luis Chamberlain 2019-07-02 20:51 ` Luis Chamberlain 2019-07-03 7:40 ` Greg Kroah-Hartman 2019-07-03 7:40 ` Greg Kroah-Hartman 2019-07-03 16:50 ` Luis Chamberlain [this message] 2019-07-03 16:50 ` Luis Chamberlain 2019-07-03 18:57 ` Greg Kroah-Hartman 2019-07-03 18:57 ` Greg Kroah-Hartman 2019-07-03 22:25 ` Luis Chamberlain 2019-07-03 22:25 ` Luis Chamberlain 2019-07-11 23:07 ` Brendan Higgins 2019-07-11 23:07 ` Brendan Higgins 2019-07-11 23:22 ` Luis Chamberlain 2019-07-11 23:22 ` Luis Chamberlain 2019-07-03 12:16 ` Enrico Weigelt, metux IT consult 2019-07-03 12:16 ` Enrico Weigelt, metux IT consult 2019-07-03 17:35 ` Luis Chamberlain 2019-07-03 17:35 ` Luis Chamberlain 2019-07-03 19:31 ` Enrico Weigelt, metux IT consult 2019-07-03 19:31 ` Enrico Weigelt, metux IT consult 2019-07-03 22:42 ` Luis Chamberlain 2019-07-03 22:42 ` Luis Chamberlain 2019-07-11 23:27 ` Brendan Higgins 2019-07-11 23:27 ` Brendan Higgins 2019-07-13 14:44 ` Enrico Weigelt, metux IT consult 2019-07-13 14:44 ` Enrico Weigelt, metux IT consult
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=20190703165020.GV19023@42.do-not-panic.com \ --to=mcgrof@kernel.org \ --cc=James.Bottomley@hansenpartnership.com \ --cc=akpm@linux-foundation.org \ --cc=backports@vger.kernel.org \ --cc=brendanhiggins@google.com \ --cc=cristina.moraru09@gmail.com \ --cc=danijons@student.chalmers.se \ --cc=dmitry.torokhov@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=hare@suse.de \ --cc=hauke@hauke-m.de \ --cc=hch@lst.de \ --cc=johannes@sipsolutions.net \ --cc=jthumshirn@suse.de \ --cc=kay@vrfy.org \ --cc=khoroshilov@ispras.ru \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=loberman@redhat.com \ --cc=martin.petersen@oracle.com \ --cc=mchehab@osg.samsung.com \ --cc=mmarek@suse.com \ --cc=paul.gortmaker@windriver.com \ --cc=pebolle@tiscali.nl \ --cc=rafael.j.wysocki@intel.com \ --cc=rusty@rustcorp.com.au \ --cc=sam@ravnborg.org \ --cc=sathya.prakash@broadcom.com \ --cc=teg@jklm.no \ --cc=tiwai@suse.de \ --cc=tj@kernel.org \ --cc=tytso@mit.edu \ --cc=valentinrothberg@gmail.com \ --cc=vegard.nossum@gmail.com \ --cc=wasowski@itu.dk \ /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: linkBe 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.