All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	will.deacon-5wv7dgnIgG8@public.gmane.org,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
Cc: Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs
Date: Thu, 21 Nov 2013 13:15:58 +0000	[thread overview]
Message-ID: <20131121131558.E5B82C40A2C@trevor.secretlab.ca> (raw)
In-Reply-To: <1384853593-32202-3-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

On Tue, 19 Nov 2013 11:33:06 +0200, Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> IOMMU devices on the bus need to be poplulated first, then iommu
> master devices are done later.
> 
> With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify
> whether a device can be an iommu msater or not. If a device can, we'll
> defer to populate that device till an iommu device is populated. Once
> an iommu device is populated, "dev->bus->iommu_ops" is set in the
> bus. Then, those defered iommu master devices are populated and
> configured for IOMMU with help of the already populated iommu device
> via iommu_ops->add_device(). Multiple IOMMUs can be listed on this
> "iommus" binding so that a device can have multiple IOMMUs attached.
> 
> Signed-off-by: Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> v5:
> Use "iommus=" binding instread of arm,smmu's "#stream-id-cells".
> 
> v4:
> This is newly added, and the successor of the following RFC:
>   [RFC][PATCHv3+ 1/2] driver/core: Add of_iommu_attach()
>   http://lists.linuxfoundation.org/pipermail/iommu/2013-November/006914.html
> ---
>  drivers/base/dd.c        |  5 +++++
>  drivers/iommu/of_iommu.c | 22 ++++++++++++++++++++++
>  include/linux/of_iommu.h |  7 +++++++
>  3 files changed, 34 insertions(+)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 35fa368..6e892d4 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -25,6 +25,7 @@
>  #include <linux/async.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/pinctrl/devinfo.h>
> +#include <linux/of_iommu.h>
>  
>  #include "base.h"
>  #include "power/power.h"
> @@ -273,6 +274,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>  
>  	dev->driver = drv;
>  
> +	ret = of_iommu_attach(dev);
> +	if (ret)
> +		goto probe_failed;
> +
>  	/* If using pinctrl, bind pins now before probing */
>  	ret = pinctrl_bind_pins(dev);
>  	if (ret)

I'm very concerned about this approach. Hooking into the core probe
path for things like this is not going to scale well. I'm not thrilled
with the pinctrl hook being here either, but that is already merged. :-(
Also, hooking in here is going affect every single device device driver
probe path, and a large number of them are never, ever, going to have
iommu interactions.

There needs to be a less invasive way of doing what you want. I still
feel like the individual device drivers themselves need to be aware that
they might be hooking through an IOMMU. Or, if they are hooking through
a bus like PCIe, then have the PCIe bus defer creating child devices
until the IOMMU is configured and in place.

g.

WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@linaro.org>
To: Hiroshi Doyu <hdoyu@nvidia.com>,
	swarren@nvidia.com, will.deacon@arm.com,
	thierry.reding@gmail.com, swarren@wwwdotorg.org,
	galak@codeaurora.org
Cc: Hiroshi Doyu <hdoyu@nvidia.com>,
	mark.rutland@arm.com, devicetree@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-tegra@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, lorenzo.pieralisi@arm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs
Date: Thu, 21 Nov 2013 13:15:58 +0000	[thread overview]
Message-ID: <20131121131558.E5B82C40A2C@trevor.secretlab.ca> (raw)
In-Reply-To: <1384853593-32202-3-git-send-email-hdoyu@nvidia.com>

On Tue, 19 Nov 2013 11:33:06 +0200, Hiroshi Doyu <hdoyu@nvidia.com> wrote:
> IOMMU devices on the bus need to be poplulated first, then iommu
> master devices are done later.
> 
> With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify
> whether a device can be an iommu msater or not. If a device can, we'll
> defer to populate that device till an iommu device is populated. Once
> an iommu device is populated, "dev->bus->iommu_ops" is set in the
> bus. Then, those defered iommu master devices are populated and
> configured for IOMMU with help of the already populated iommu device
> via iommu_ops->add_device(). Multiple IOMMUs can be listed on this
> "iommus" binding so that a device can have multiple IOMMUs attached.
> 
> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
> ---
> v5:
> Use "iommus=" binding instread of arm,smmu's "#stream-id-cells".
> 
> v4:
> This is newly added, and the successor of the following RFC:
>   [RFC][PATCHv3+ 1/2] driver/core: Add of_iommu_attach()
>   http://lists.linuxfoundation.org/pipermail/iommu/2013-November/006914.html
> ---
>  drivers/base/dd.c        |  5 +++++
>  drivers/iommu/of_iommu.c | 22 ++++++++++++++++++++++
>  include/linux/of_iommu.h |  7 +++++++
>  3 files changed, 34 insertions(+)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 35fa368..6e892d4 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -25,6 +25,7 @@
>  #include <linux/async.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/pinctrl/devinfo.h>
> +#include <linux/of_iommu.h>
>  
>  #include "base.h"
>  #include "power/power.h"
> @@ -273,6 +274,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>  
>  	dev->driver = drv;
>  
> +	ret = of_iommu_attach(dev);
> +	if (ret)
> +		goto probe_failed;
> +
>  	/* If using pinctrl, bind pins now before probing */
>  	ret = pinctrl_bind_pins(dev);
>  	if (ret)

I'm very concerned about this approach. Hooking into the core probe
path for things like this is not going to scale well. I'm not thrilled
with the pinctrl hook being here either, but that is already merged. :-(
Also, hooking in here is going affect every single device device driver
probe path, and a large number of them are never, ever, going to have
iommu interactions.

There needs to be a less invasive way of doing what you want. I still
feel like the individual device drivers themselves need to be aware that
they might be hooking through an IOMMU. Or, if they are hooking through
a bus like PCIe, then have the PCIe bus defer creating child devices
until the IOMMU is configured and in place.

g.

WARNING: multiple messages have this Message-ID (diff)
From: grant.likely@linaro.org (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs
Date: Thu, 21 Nov 2013 13:15:58 +0000	[thread overview]
Message-ID: <20131121131558.E5B82C40A2C@trevor.secretlab.ca> (raw)
In-Reply-To: <1384853593-32202-3-git-send-email-hdoyu@nvidia.com>

On Tue, 19 Nov 2013 11:33:06 +0200, Hiroshi Doyu <hdoyu@nvidia.com> wrote:
> IOMMU devices on the bus need to be poplulated first, then iommu
> master devices are done later.
> 
> With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify
> whether a device can be an iommu msater or not. If a device can, we'll
> defer to populate that device till an iommu device is populated. Once
> an iommu device is populated, "dev->bus->iommu_ops" is set in the
> bus. Then, those defered iommu master devices are populated and
> configured for IOMMU with help of the already populated iommu device
> via iommu_ops->add_device(). Multiple IOMMUs can be listed on this
> "iommus" binding so that a device can have multiple IOMMUs attached.
> 
> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
> ---
> v5:
> Use "iommus=" binding instread of arm,smmu's "#stream-id-cells".
> 
> v4:
> This is newly added, and the successor of the following RFC:
>   [RFC][PATCHv3+ 1/2] driver/core: Add of_iommu_attach()
>   http://lists.linuxfoundation.org/pipermail/iommu/2013-November/006914.html
> ---
>  drivers/base/dd.c        |  5 +++++
>  drivers/iommu/of_iommu.c | 22 ++++++++++++++++++++++
>  include/linux/of_iommu.h |  7 +++++++
>  3 files changed, 34 insertions(+)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 35fa368..6e892d4 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -25,6 +25,7 @@
>  #include <linux/async.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/pinctrl/devinfo.h>
> +#include <linux/of_iommu.h>
>  
>  #include "base.h"
>  #include "power/power.h"
> @@ -273,6 +274,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>  
>  	dev->driver = drv;
>  
> +	ret = of_iommu_attach(dev);
> +	if (ret)
> +		goto probe_failed;
> +
>  	/* If using pinctrl, bind pins now before probing */
>  	ret = pinctrl_bind_pins(dev);
>  	if (ret)

I'm very concerned about this approach. Hooking into the core probe
path for things like this is not going to scale well. I'm not thrilled
with the pinctrl hook being here either, but that is already merged. :-(
Also, hooking in here is going affect every single device device driver
probe path, and a large number of them are never, ever, going to have
iommu interactions.

There needs to be a less invasive way of doing what you want. I still
feel like the individual device drivers themselves need to be aware that
they might be hooking through an IOMMU. Or, if they are hooking through
a bus like PCIe, then have the PCIe bus defer creating child devices
until the IOMMU is configured and in place.

g.

  parent reply	other threads:[~2013-11-21 13:15 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19  9:33 [PATCHv5 0/9] Unifying Tegra IOMMU(SMMU) driver among Tegra SoCs Hiroshi Doyu
2013-11-19  9:33 ` Hiroshi Doyu
2013-11-19  9:33 ` Hiroshi Doyu
     [not found] ` < 1384853593-32202-3-git-send-email-hdoyu@nvidia.com>
     [not found] ` <1384853593-32202-1-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19  9:33   ` [PATCHv5 1/9] of: introduce of_property_for_earch_phandle_with_args() Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33   ` [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found]     ` <1384853593-32202-3-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 10:25       ` Thierry Reding
2013-11-19 10:25         ` Thierry Reding
2013-11-19 10:25         ` Thierry Reding
     [not found]         ` <20131119102506.GG31504-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-11-19 12:03           ` Hiroshi Doyu
2013-11-19 12:03             ` Hiroshi Doyu
2013-11-19 12:03             ` Hiroshi Doyu
     [not found]             ` <20131119.140351.1342214267287135109.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 21:22               ` Stephen Warren
2013-11-19 21:22                 ` Stephen Warren
2013-11-19 21:22                 ` Stephen Warren
     [not found]                 ` <528BD6A7.3030908-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-20  3:17                   ` Hiroshi Doyu
2013-11-20  3:17                     ` Hiroshi Doyu
2013-11-20  3:17                     ` Hiroshi Doyu
     [not found]                     ` <20131120.051708.396722414386125310.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-20 13:14                       ` Thierry Reding
2013-11-20 13:14                         ` Thierry Reding
2013-11-20 13:14                         ` Thierry Reding
     [not found]                         ` <20131120131447.GA8279-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-11-20 14:03                           ` Hiroshi Doyu
2013-11-20 14:03                             ` Hiroshi Doyu
2013-11-20 14:03                             ` Hiroshi Doyu
     [not found]                             ` <20131120.160359.1043627108929095327.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-20 16:30                               ` Stephen Warren
2013-11-20 16:30                                 ` Stephen Warren
2013-11-20 16:30                                 ` Stephen Warren
     [not found]                                 ` <528CE3AB.60806-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-21  9:01                                   ` Hiroshi Doyu
2013-11-21  9:01                                     ` Hiroshi Doyu
2013-11-21  9:01                                     ` Hiroshi Doyu
2013-11-21 13:15       ` Grant Likely [this message]
2013-11-21 13:15         ` Grant Likely
2013-11-21 13:15         ` Grant Likely
     [not found]         ` <20131121131558.E5B82C40A2C-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-21 19:04           ` Stephen Warren
2013-11-21 19:04             ` Stephen Warren
2013-11-21 19:04             ` Stephen Warren
     [not found]             ` <528E5932.1070105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-22  7:41               ` Grant Likely
2013-11-22  7:41                 ` Grant Likely
2013-11-22  7:41                 ` Grant Likely
     [not found]                 ` <20131122074111.155E2C40753-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-22 17:35                   ` Stephen Warren
2013-11-22 17:35                     ` Stephen Warren
2013-11-22 17:35                     ` Stephen Warren
     [not found]                     ` <528F95FE.7080406-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-25 17:39                       ` Will Deacon
2013-11-25 17:39                         ` Will Deacon
2013-11-25 17:39                         ` Will Deacon
2013-11-19  9:33   ` [PATCHv5 3/9] ARM: tegra: create a DT header defining SWGROUP ID Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found]     ` <1384853593-32202-4-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 21:36       ` Stephen Warren
2013-11-19 21:36         ` Stephen Warren
2013-11-19 21:36         ` Stephen Warren
2013-11-19  9:33   ` [PATCHv5 4/9] iommu/tegra: smmu: register device to iommu dynamically Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found]     ` <1384853593-32202-5-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 21:39       ` Stephen Warren
2013-11-19 21:39         ` Stephen Warren
2013-11-19 21:39         ` Stephen Warren
2013-11-19  9:33   ` [PATCHv5 5/9] iommu/tegra: smmu: calculate ASID register offset by ID Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33   ` [PATCHv5 6/9] iommu/tegra: smmu: get swgroups from DT "iommus=" Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found]     ` <1384853593-32202-7-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 21:52       ` Stephen Warren
2013-11-19 21:52         ` Stephen Warren
2013-11-19 21:52         ` Stephen Warren
2013-11-19  9:33   ` [PATCHv5 7/9] iommu/tegra: smmu: allow duplicate ASID wirte Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33   ` [PATCHv5 8/9] iommu/tegra: smmu: Rename hwgrp -> swgroups Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33   ` [PATCHv5 9/9] [FOR TEST] ARM: dt: tegra30: add "iommus" binding Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found] ` < 1384853593-32202-2-git-send-email-hdoyu@nvidia.com>
     [not found]   ` <1384853593-32202-2-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-21 12:43     ` [PATCHv5 1/9] of: introduce of_property_for_earch_phandle_with_args() Grant Likely
2013-11-21 12:43       ` Grant Likely
2013-11-21 12:43       ` Grant Likely
     [not found]       ` <20131121124328.46BC1C40A2C-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-21 13:12         ` Hiroshi Doyu
2013-11-21 13:12           ` Hiroshi Doyu
2013-11-21 13:12           ` Hiroshi Doyu
     [not found]   ` <20131121124328. 46BC1C40A2C@trevor.secretlab.ca>
     [not found]     ` <20131121151218.befbb483c0cf09cdcd4cd4dd@ nvidia.com>
     [not found]       ` <20131121151218.befbb483c0cf09cdcd4cd4dd-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-21 15:56         ` Grant Likely
2013-11-21 15:56           ` Grant Likely
2013-11-21 15:56           ` Grant Likely
     [not found]           ` <20131121155649.48C96C406A3-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-21 17:20             ` Hiroshi Doyu
2013-11-21 17:20               ` Hiroshi Doyu
2013-11-21 17:20               ` Hiroshi Doyu
     [not found]               ` <20131121.192051.747601347584525020.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-21 18:52                 ` Stephen Warren
2013-11-21 18:52                   ` Stephen Warren
2013-11-21 18:52                   ` Stephen Warren
2013-11-21 21:36                 ` Rob Herring
2013-11-21 21:36                   ` Rob Herring
2013-11-21 21:36                   ` Rob Herring
     [not found] ` < 1384853593-32202-5-git-send-email-hdoyu@nvidia.com>
     [not found]   ` <528BDAAA.4000203@ wwwdotorg.org>
     [not found]     ` <528BDAAA.4000203-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-21 13:23       ` [PATCHv5 4/9] iommu/tegra: smmu: register device to iommu dynamically Grant Likely
2013-11-21 13:23         ` Grant Likely
2013-11-21 13:23         ` Grant Likely
     [not found]         ` <20131121132322.EFDD1C40A2C-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-21 13:38           ` Hiroshi Doyu
2013-11-21 13:38             ` Hiroshi Doyu
2013-11-21 13:38             ` Hiroshi Doyu

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=20131121131558.E5B82C40A2C@trevor.secretlab.ca \
    --to=grant.likely-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    /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.