All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: devel@driverdev.osuosl.org, Lars-Peter Clausen <lars@metafoo.de>,
	linux-iio@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Barry Song <21cnbao@gmail.com>,
	linux-kernel@vger.kernel.org,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Hartmut Knaack <knaack.h@gmx.de>,
	daniel.baluta@nxp.com
Subject: Re: [PATCH v2 1/8] staging:iio:ade7854: Fix error handling on read/write
Date: Mon, 19 Mar 2018 22:53:39 -0300	[thread overview]
Message-ID: <20180320015339.3hald4gulfmul4e5@smtp.gmail.com> (raw)
In-Reply-To: <20180318094541.24331a00@archlinux>

On 03/18, Jonathan Cameron wrote:
> On Fri, 16 Mar 2018 19:48:33 -0300
> Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> wrote:
> 
> > The original code does not correctly handle the error related to I2C
> > read and write. This patch fixes the error handling related to all
> > read/write functions for I2C. This patch is an adaptation of the John
> > Syne patches.
> > 
> > Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> > Signed-off-by: John Syne <john3909@gmail.com>
> Hi Rodrigo,
> 
> I'm not sure what the chain of authorship was here.  If this is fundamentally
> John's original patch he should still be the author and his sign off should be
> first.  You then sign off afterwards to indicate that you 'handled' the patch
> and believe the work to be John's (you are trusting his sign off).  This
> is 'fun' legal stuff - read the docs on developers certificate of origin.
> 
> If the patch has changed 'enough' (where that is a fuzzy definition)
> then you should as you have here take the authorship, but John's sign off is
> no longer true (it's a different patch).  If John has reviewed the code
> it is fine to have a reviewed-by or acked-by from John there to reflect
> that.
> 
> Anyhow, please clarify the situation as I shouldn't take a patch where
> I'm applying my sign-off without knowing the origins etc.

Hi Jonathan,

Just for clarification, this is fundamentally John's original patch with
some changes on the way that write_reg operation returns the error. I
should ask for someone else, how to correctly handle this situation
since I did not have experience with this situation.

Actually, when I worked on this patch, I was confused about using
different authorship from the email. I got confused because of the
following statement:

"Make sure that the email you specify here is the same email you used to
set up sending mail. The Linux kernel developers will not accept a patch
where the "From" email differs from the "Signed-off-by" line, which is
what will happen if these two emails do not match." [1]

Anyway, I think this is not a newbie issue, and I should asked first.
Thanks for the great explanation, I will not make this kind of mistake
again.

Thanks

[1] - https://kernelnewbies.org/FirstKernelPatch
 
> > ---
> >  drivers/staging/iio/meter/ade7854-i2c.c | 24 ++++++++++++------------
> >  drivers/staging/iio/meter/ade7854.c     | 10 +++++-----
> >  2 files changed, 17 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/staging/iio/meter/ade7854-i2c.c b/drivers/staging/iio/meter/ade7854-i2c.c
> > index 317e4f0d8176..4437f1e33261 100644
> > --- a/drivers/staging/iio/meter/ade7854-i2c.c
> > +++ b/drivers/staging/iio/meter/ade7854-i2c.c
> > @@ -31,7 +31,7 @@ static int ade7854_i2c_write_reg_8(struct device *dev,
> >  	ret = i2c_master_send(st->i2c, st->tx, 3);
> >  	mutex_unlock(&st->buf_lock);
> >  
> > -	return ret;
> > +	return ret < 0 ? ret : 0;
> >  }
> >  
> >  static int ade7854_i2c_write_reg_16(struct device *dev,
> > @@ -51,7 +51,7 @@ static int ade7854_i2c_write_reg_16(struct device *dev,
> >  	ret = i2c_master_send(st->i2c, st->tx, 4);
> >  	mutex_unlock(&st->buf_lock);
> >  
> > -	return ret;
> > +	return ret < 0 ? ret : 0;
> >  }
> >  
> >  static int ade7854_i2c_write_reg_24(struct device *dev,
> > @@ -72,7 +72,7 @@ static int ade7854_i2c_write_reg_24(struct device *dev,
> >  	ret = i2c_master_send(st->i2c, st->tx, 5);
> >  	mutex_unlock(&st->buf_lock);
> >  
> > -	return ret;
> > +	return ret < 0 ? ret : 0;
> >  }
> >  
> >  static int ade7854_i2c_write_reg_32(struct device *dev,
> > @@ -94,7 +94,7 @@ static int ade7854_i2c_write_reg_32(struct device *dev,
> >  	ret = i2c_master_send(st->i2c, st->tx, 6);
> >  	mutex_unlock(&st->buf_lock);
> >  
> > -	return ret;
> > +	return ret < 0 ? ret : 0;
> >  }
> So for write cases you are flattening to 0 for good and < 0 for bad.
> good.
> >  
> >  static int ade7854_i2c_read_reg_8(struct device *dev,
> > @@ -110,11 +110,11 @@ static int ade7854_i2c_read_reg_8(struct device *dev,
> >  	st->tx[1] = reg_address & 0xFF;
> >  
> >  	ret = i2c_master_send(st->i2c, st->tx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	ret = i2c_master_recv(st->i2c, st->rx, 1);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	*val = st->rx[0];
> But in read cases you are returning the number of bytes read...
> Given these functions can know the 'right' answer to that why not check
> it here and do the same as for writes in return 0 for good and < 0 for
> bad?
> > @@ -136,11 +136,11 @@ static int ade7854_i2c_read_reg_16(struct device *dev,
> >  	st->tx[1] = reg_address & 0xFF;
> >  
> >  	ret = i2c_master_send(st->i2c, st->tx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	ret = i2c_master_recv(st->i2c, st->rx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	*val = (st->rx[0] << 8) | st->rx[1];
> > @@ -162,11 +162,11 @@ static int ade7854_i2c_read_reg_24(struct device *dev,
> >  	st->tx[1] = reg_address & 0xFF;
> >  
> >  	ret = i2c_master_send(st->i2c, st->tx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	ret = i2c_master_recv(st->i2c, st->rx, 3);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	*val = (st->rx[0] << 16) | (st->rx[1] << 8) | st->rx[2];
> > @@ -188,11 +188,11 @@ static int ade7854_i2c_read_reg_32(struct device *dev,
> >  	st->tx[1] = reg_address & 0xFF;
> >  
> >  	ret = i2c_master_send(st->i2c, st->tx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	ret = i2c_master_recv(st->i2c, st->rx, 3);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	*val = (st->rx[0] << 24) | (st->rx[1] << 16) |
> > diff --git a/drivers/staging/iio/meter/ade7854.c b/drivers/staging/iio/meter/ade7854.c
> > index 90d07cdca4b8..0193ae3aae29 100644
> > --- a/drivers/staging/iio/meter/ade7854.c
> > +++ b/drivers/staging/iio/meter/ade7854.c
> > @@ -33,7 +33,7 @@ static ssize_t ade7854_read_8bit(struct device *dev,
> >  	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> >  
> >  	ret = st->read_reg_8(dev, this_attr->address, &val);
> > -	if (ret)
> > +	if (ret < 0)
> If you did as discussed above with the reads then this change would not
> be needed and all the changes would be confined to the i2c code.
> 
> Thanks,
> 
> Jonathan
> 
> 
> >  		return ret;
> >  
> >  	return sprintf(buf, "%u\n", val);
> > @@ -50,7 +50,7 @@ static ssize_t ade7854_read_16bit(struct device *dev,
> >  	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> >  
> >  	ret = st->read_reg_16(dev, this_attr->address, &val);
> > -	if (ret)
> > +	if (ret < 0)
> >  		return ret;
> >  
> >  	return sprintf(buf, "%u\n", val);
> > @@ -67,7 +67,7 @@ static ssize_t ade7854_read_24bit(struct device *dev,
> >  	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> >  
> >  	ret = st->read_reg_24(dev, this_attr->address, &val);
> > -	if (ret)
> > +	if (ret < 0)
> >  		return ret;
> >  
> >  	return sprintf(buf, "%u\n", val);
> > @@ -84,7 +84,7 @@ static ssize_t ade7854_read_32bit(struct device *dev,
> >  	struct ade7854_state *st = iio_priv(indio_dev);
> >  
> >  	ret = st->read_reg_32(dev, this_attr->address, &val);
> > -	if (ret)
> > +	if (ret < 0)
> >  		return ret;
> >  
> >  	return sprintf(buf, "%u\n", val);
> > @@ -416,7 +416,7 @@ static int ade7854_set_irq(struct device *dev, bool enable)
> >  	u32 irqen;
> >  
> >  	ret = st->read_reg_32(dev, ADE7854_MASK0, &irqen);
> > -	if (ret)
> > +	if (ret < 0)
> >  		return ret;
> >  
> >  	if (enable)
> 
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: John Syne <john3909@gmail.com>, Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org, Barry Song <21cnbao@gmail.com>,
	daniel.baluta@nxp.com
Subject: Re: [PATCH v2 1/8] staging:iio:ade7854: Fix error handling on read/write
Date: Mon, 19 Mar 2018 22:53:39 -0300	[thread overview]
Message-ID: <20180320015339.3hald4gulfmul4e5@smtp.gmail.com> (raw)
In-Reply-To: <20180318094541.24331a00@archlinux>

On 03/18, Jonathan Cameron wrote:
> On Fri, 16 Mar 2018 19:48:33 -0300
> Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> wrote:
> 
> > The original code does not correctly handle the error related to I2C
> > read and write. This patch fixes the error handling related to all
> > read/write functions for I2C. This patch is an adaptation of the John
> > Syne patches.
> > 
> > Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
> > Signed-off-by: John Syne <john3909@gmail.com>
> Hi Rodrigo,
> 
> I'm not sure what the chain of authorship was here.  If this is fundamentally
> John's original patch he should still be the author and his sign off should be
> first.  You then sign off afterwards to indicate that you 'handled' the patch
> and believe the work to be John's (you are trusting his sign off).  This
> is 'fun' legal stuff - read the docs on developers certificate of origin.
> 
> If the patch has changed 'enough' (where that is a fuzzy definition)
> then you should as you have here take the authorship, but John's sign off is
> no longer true (it's a different patch).  If John has reviewed the code
> it is fine to have a reviewed-by or acked-by from John there to reflect
> that.
> 
> Anyhow, please clarify the situation as I shouldn't take a patch where
> I'm applying my sign-off without knowing the origins etc.

Hi Jonathan,

Just for clarification, this is fundamentally John's original patch with
some changes on the way that write_reg operation returns the error. I
should ask for someone else, how to correctly handle this situation
since I did not have experience with this situation.

Actually, when I worked on this patch, I was confused about using
different authorship from the email. I got confused because of the
following statement:

"Make sure that the email you specify here is the same email you used to
set up sending mail. The Linux kernel developers will not accept a patch
where the "From" email differs from the "Signed-off-by" line, which is
what will happen if these two emails do not match." [1]

Anyway, I think this is not a newbie issue, and I should asked first.
Thanks for the great explanation, I will not make this kind of mistake
again.

Thanks

[1] - https://kernelnewbies.org/FirstKernelPatch
 
> > ---
> >  drivers/staging/iio/meter/ade7854-i2c.c | 24 ++++++++++++------------
> >  drivers/staging/iio/meter/ade7854.c     | 10 +++++-----
> >  2 files changed, 17 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/staging/iio/meter/ade7854-i2c.c b/drivers/staging/iio/meter/ade7854-i2c.c
> > index 317e4f0d8176..4437f1e33261 100644
> > --- a/drivers/staging/iio/meter/ade7854-i2c.c
> > +++ b/drivers/staging/iio/meter/ade7854-i2c.c
> > @@ -31,7 +31,7 @@ static int ade7854_i2c_write_reg_8(struct device *dev,
> >  	ret = i2c_master_send(st->i2c, st->tx, 3);
> >  	mutex_unlock(&st->buf_lock);
> >  
> > -	return ret;
> > +	return ret < 0 ? ret : 0;
> >  }
> >  
> >  static int ade7854_i2c_write_reg_16(struct device *dev,
> > @@ -51,7 +51,7 @@ static int ade7854_i2c_write_reg_16(struct device *dev,
> >  	ret = i2c_master_send(st->i2c, st->tx, 4);
> >  	mutex_unlock(&st->buf_lock);
> >  
> > -	return ret;
> > +	return ret < 0 ? ret : 0;
> >  }
> >  
> >  static int ade7854_i2c_write_reg_24(struct device *dev,
> > @@ -72,7 +72,7 @@ static int ade7854_i2c_write_reg_24(struct device *dev,
> >  	ret = i2c_master_send(st->i2c, st->tx, 5);
> >  	mutex_unlock(&st->buf_lock);
> >  
> > -	return ret;
> > +	return ret < 0 ? ret : 0;
> >  }
> >  
> >  static int ade7854_i2c_write_reg_32(struct device *dev,
> > @@ -94,7 +94,7 @@ static int ade7854_i2c_write_reg_32(struct device *dev,
> >  	ret = i2c_master_send(st->i2c, st->tx, 6);
> >  	mutex_unlock(&st->buf_lock);
> >  
> > -	return ret;
> > +	return ret < 0 ? ret : 0;
> >  }
> So for write cases you are flattening to 0 for good and < 0 for bad.
> good.
> >  
> >  static int ade7854_i2c_read_reg_8(struct device *dev,
> > @@ -110,11 +110,11 @@ static int ade7854_i2c_read_reg_8(struct device *dev,
> >  	st->tx[1] = reg_address & 0xFF;
> >  
> >  	ret = i2c_master_send(st->i2c, st->tx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	ret = i2c_master_recv(st->i2c, st->rx, 1);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	*val = st->rx[0];
> But in read cases you are returning the number of bytes read...
> Given these functions can know the 'right' answer to that why not check
> it here and do the same as for writes in return 0 for good and < 0 for
> bad?
> > @@ -136,11 +136,11 @@ static int ade7854_i2c_read_reg_16(struct device *dev,
> >  	st->tx[1] = reg_address & 0xFF;
> >  
> >  	ret = i2c_master_send(st->i2c, st->tx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	ret = i2c_master_recv(st->i2c, st->rx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	*val = (st->rx[0] << 8) | st->rx[1];
> > @@ -162,11 +162,11 @@ static int ade7854_i2c_read_reg_24(struct device *dev,
> >  	st->tx[1] = reg_address & 0xFF;
> >  
> >  	ret = i2c_master_send(st->i2c, st->tx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	ret = i2c_master_recv(st->i2c, st->rx, 3);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	*val = (st->rx[0] << 16) | (st->rx[1] << 8) | st->rx[2];
> > @@ -188,11 +188,11 @@ static int ade7854_i2c_read_reg_32(struct device *dev,
> >  	st->tx[1] = reg_address & 0xFF;
> >  
> >  	ret = i2c_master_send(st->i2c, st->tx, 2);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	ret = i2c_master_recv(st->i2c, st->rx, 3);
> > -	if (ret)
> > +	if (ret < 0)
> >  		goto out;
> >  
> >  	*val = (st->rx[0] << 24) | (st->rx[1] << 16) |
> > diff --git a/drivers/staging/iio/meter/ade7854.c b/drivers/staging/iio/meter/ade7854.c
> > index 90d07cdca4b8..0193ae3aae29 100644
> > --- a/drivers/staging/iio/meter/ade7854.c
> > +++ b/drivers/staging/iio/meter/ade7854.c
> > @@ -33,7 +33,7 @@ static ssize_t ade7854_read_8bit(struct device *dev,
> >  	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> >  
> >  	ret = st->read_reg_8(dev, this_attr->address, &val);
> > -	if (ret)
> > +	if (ret < 0)
> If you did as discussed above with the reads then this change would not
> be needed and all the changes would be confined to the i2c code.
> 
> Thanks,
> 
> Jonathan
> 
> 
> >  		return ret;
> >  
> >  	return sprintf(buf, "%u\n", val);
> > @@ -50,7 +50,7 @@ static ssize_t ade7854_read_16bit(struct device *dev,
> >  	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> >  
> >  	ret = st->read_reg_16(dev, this_attr->address, &val);
> > -	if (ret)
> > +	if (ret < 0)
> >  		return ret;
> >  
> >  	return sprintf(buf, "%u\n", val);
> > @@ -67,7 +67,7 @@ static ssize_t ade7854_read_24bit(struct device *dev,
> >  	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> >  
> >  	ret = st->read_reg_24(dev, this_attr->address, &val);
> > -	if (ret)
> > +	if (ret < 0)
> >  		return ret;
> >  
> >  	return sprintf(buf, "%u\n", val);
> > @@ -84,7 +84,7 @@ static ssize_t ade7854_read_32bit(struct device *dev,
> >  	struct ade7854_state *st = iio_priv(indio_dev);
> >  
> >  	ret = st->read_reg_32(dev, this_attr->address, &val);
> > -	if (ret)
> > +	if (ret < 0)
> >  		return ret;
> >  
> >  	return sprintf(buf, "%u\n", val);
> > @@ -416,7 +416,7 @@ static int ade7854_set_irq(struct device *dev, bool enable)
> >  	u32 irqen;
> >  
> >  	ret = st->read_reg_32(dev, ADE7854_MASK0, &irqen);
> > -	if (ret)
> > +	if (ret < 0)
> >  		return ret;
> >  
> >  	if (enable)
> 

  reply	other threads:[~2018-03-20  1:53 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-16 22:48 [PATCH v2 0/8] staging:iio:ade7854: Cleanup on I2C/SPI code Rodrigo Siqueira
2018-03-16 22:48 ` Rodrigo Siqueira
2018-03-16 22:48 ` [PATCH v2 1/8] staging:iio:ade7854: Fix error handling on read/write Rodrigo Siqueira
2018-03-16 22:48   ` Rodrigo Siqueira
2018-03-18  9:45   ` Jonathan Cameron
2018-03-18  9:45     ` Jonathan Cameron
2018-03-20  1:53     ` Rodrigo Siqueira [this message]
2018-03-20  1:53       ` Rodrigo Siqueira
2018-03-16 22:48 ` [PATCH v2 2/8] staging:iio:ade7854: Fix the wrong number of bits to read Rodrigo Siqueira
2018-03-16 22:48   ` Rodrigo Siqueira
2018-03-18  9:48   ` Jonathan Cameron
2018-03-18  9:48     ` Jonathan Cameron
2018-03-16 22:49 ` [PATCH v2 3/8] staging:iio:ade7854: Rework I2C write function Rodrigo Siqueira
2018-03-16 22:49   ` Rodrigo Siqueira
2018-03-18  9:56   ` Jonathan Cameron
2018-03-18  9:56     ` Jonathan Cameron
2018-03-16 22:49 ` [PATCH v2 4/8] staging:iio:ade7854: Rework SPI " Rodrigo Siqueira
2018-03-16 22:49   ` Rodrigo Siqueira
2018-03-18  9:57   ` Jonathan Cameron
2018-03-18  9:57     ` Jonathan Cameron
2018-03-16 22:49 ` [PATCH v2 5/8] staging:iio:ade7854: Replace many functions for one function Rodrigo Siqueira
2018-03-16 22:49   ` Rodrigo Siqueira
2018-03-18  9:58   ` Jonathan Cameron
2018-03-18  9:58     ` Jonathan Cameron
2018-03-16 22:49 ` [PATCH v2 6/8] staging:iio:ade7854: Rework I2C read function Rodrigo Siqueira
2018-03-16 22:49   ` Rodrigo Siqueira
2018-03-18 10:00   ` Jonathan Cameron
2018-03-18 10:00     ` Jonathan Cameron
2018-03-16 22:50 ` [PATCH v2 7/8] staging:iio:ade7854: Rework SPI " Rodrigo Siqueira
2018-03-16 22:50   ` Rodrigo Siqueira
2018-03-16 22:50 ` [PATCH v2 8/8] staging:iio:ade7854: Remove read_reg_* duplications Rodrigo Siqueira
2018-03-16 22:50   ` Rodrigo Siqueira
2018-03-18 10:05   ` Jonathan Cameron
2018-03-18 10:05     ` Jonathan Cameron

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=20180320015339.3hald4gulfmul4e5@smtp.gmail.com \
    --to=rodrigosiqueiramelo@gmail.com \
    --cc=21cnbao@gmail.com \
    --cc=daniel.baluta@nxp.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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.