* [PATCH] ASoC: topology: Add support for TLV bytes control
@ 2015-08-12 2:10 mengdong.lin
2015-08-13 1:41 ` Lin, Mengdong
2015-08-14 19:17 ` Mark Brown
0 siblings, 2 replies; 6+ messages in thread
From: mengdong.lin @ 2015-08-12 2:10 UTC (permalink / raw
To: alsa-devel; +Cc: tiwai, Mengdong Lin, broonie, liam.r.girdwood
From: Mengdong Lin <mengdong.lin@intel.com>
Allow vendor drivers to define bespoke bytes ext handlers and IDs for
TLV bytes controls. And the topology core will bind these handlers by
matching IDs defined by the vendor driver and user space topology
data file.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
diff --git a/include/sound/soc-topology.h b/include/sound/soc-topology.h
index 865a141..3e412c6 100644
--- a/include/sound/soc-topology.h
+++ b/include/sound/soc-topology.h
@@ -89,6 +89,13 @@ struct snd_soc_tplg_kcontrol_ops {
struct snd_ctl_elem_info *uinfo);
};
+/* Bytes ext operations, for TLV byte controls */
+struct snd_soc_tplg_bytes_ext_ops {
+ u32 id;
+ int (*get)(unsigned int __user *bytes, unsigned int size);
+ int (*put)(const unsigned int __user *bytes, unsigned int size);
+};
+
/*
* DAPM widget event handlers - used to map handlers onto widgets.
*/
@@ -139,6 +146,10 @@ struct snd_soc_tplg_ops {
/* bespoke kcontrol handlers available for binding */
const struct snd_soc_tplg_kcontrol_ops *io_ops;
int io_ops_count;
+
+ /* bespoke bytes ext handlers available for binding */
+ const struct snd_soc_tplg_bytes_ext_ops *bytes_ext_ops;
+ int bytes_ext_ops_count;
};
/* gets a pointer to data from the firmware block header */
diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c
index 607f98b..b5a2868 100644
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -70,6 +70,10 @@ struct soc_tplg {
const struct snd_soc_tplg_kcontrol_ops *io_ops;
int io_ops_count;
+ /* bespoke bytes ext handlers, for TLV bytes controls */
+ const struct snd_soc_tplg_bytes_ext_ops *bytes_ext_ops;
+ int bytes_ext_ops_count;
+
/* optional fw loading callbacks to component drivers */
struct snd_soc_tplg_ops *ops;
};
@@ -513,6 +517,15 @@ static int soc_tplg_kcontrol_bind_io(struct snd_soc_tplg_ctl_hdr *hdr,
{
int i;
+ /* TLV bytes controls don't need get/put ops */
+ if (k->iface & SNDRV_CTL_ELEM_IFACE_MIXER
+ && k->access & SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE
+ && k->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK
+ && hdr->ops.info == SND_SOC_TPLG_CTL_BYTES) {
+ k->info = snd_soc_bytes_info_ext;
+ return 0;
+ }
+
/* try and map standard kcontrols handler first */
for (i = 0; i < num_ops; i++) {
@@ -547,6 +560,32 @@ static int soc_tplg_kcontrol_bind_io(struct snd_soc_tplg_ctl_hdr *hdr,
return -EINVAL;
}
+/* bind bytes ext get/put handlers for TLV bytes controls */
+static int soc_tplg_bytes_ext_bind_io(struct soc_tplg *tplg,
+ struct snd_soc_tplg_io_ops *ops_id,
+ struct soc_bytes_ext *sbe)
+{
+ const struct snd_soc_tplg_bytes_ext_ops *ops = tplg->bytes_ext_ops;
+ int num_ops = tplg->bytes_ext_ops_count;
+ int i;
+
+ /* try bespoke handlers */
+ for (i = 0; i < num_ops; i++) {
+
+ if (sbe->put == NULL && ops[i].id == ops_id->put)
+ sbe->put = ops[i].put;
+ if (sbe->get == NULL && ops[i].id == ops_id->get)
+ sbe->get = ops[i].get;
+ }
+
+ /* bespoke handlers found ? */
+ if (sbe->put && sbe->get)
+ return 0;
+
+ /* nothing to bind */
+ return -EINVAL;
+}
+
/* bind a widgets to it's evnt handlers */
int snd_soc_tplg_widget_bind_event(struct snd_soc_dapm_widget *w,
const struct snd_soc_tplg_widget_events *events,
@@ -690,6 +729,14 @@ static int soc_tplg_dbytes_create(struct soc_tplg *tplg, unsigned int count,
continue;
}
+ /* create any TLV data */
+ soc_tplg_create_tlv(tplg, &kc, &be->hdr);
+ /* map bytes ext io handlers for TLV bytes controls */
+ if (kc.access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
+ soc_tplg_bytes_ext_bind_io(tplg,
+ &be->ext_ops, sbe);
+ }
+
/* pass control to driver for optional further init */
err = soc_tplg_init_kcontrol(tplg, &kc,
(struct snd_soc_tplg_ctl_hdr *)be);
@@ -1315,6 +1362,14 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dbytes_create(
continue;
}
+ /* create any TLV data */
+ soc_tplg_create_tlv(tplg, &kc[i], &be->hdr);
+ /* map bytes ext io handlers for TLV bytes controls */
+ if (kc[i].access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
+ soc_tplg_bytes_ext_bind_io(tplg,
+ &be->ext_ops, sbe);
+ }
+
/* pass control to driver for optional further init */
err = soc_tplg_init_kcontrol(tplg, &kc[i],
(struct snd_soc_tplg_ctl_hdr *)be);
@@ -1736,6 +1791,8 @@ int snd_soc_tplg_component_load(struct snd_soc_component *comp,
tplg.req_index = id;
tplg.io_ops = ops->io_ops;
tplg.io_ops_count = ops->io_ops_count;
+ tplg.bytes_ext_ops = ops->bytes_ext_ops;
+ tplg.bytes_ext_ops_count = ops->bytes_ext_ops_count;
return soc_tplg_load(&tplg);
}
--
1.9.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: topology: Add support for TLV bytes control
2015-08-12 2:10 [PATCH] ASoC: topology: Add support for TLV bytes control mengdong.lin
@ 2015-08-13 1:41 ` Lin, Mengdong
2015-08-14 19:17 ` Mark Brown
1 sibling, 0 replies; 6+ messages in thread
From: Lin, Mengdong @ 2015-08-13 1:41 UTC (permalink / raw
To: broonie@kernel.org, alsa-devel@alsa-project.org
Cc: tiwai@suse.de, Girdwood, Liam R
Hi Mark,
If convenient, would you please review this patch before my another series:
"[PATCH v2 00/10] ASoC: support adding PCM dynamically from topology"?
This patch is more like a fix for TLV bytes control in topology kernel.
The user space part has been merged in alsa-lib now. We want to avoid mismatch between the kernel and user space.
That v2 series for dynamic PCM support in topology is actually still in RFC phase. We hope to get your feedback to adjust the direction and go ahead.
Thanks
Mengdong
> -----Original Message-----
> From: Lin, Mengdong
> Sent: Wednesday, August 12, 2015 10:11 AM
> To: alsa-devel@alsa-project.org
> Cc: tiwai@suse.de; broonie@kernel.org; Girdwood, Liam R; Lin, Mengdong
> Subject: [PATCH] ASoC: topology: Add support for TLV bytes control
>
> From: Mengdong Lin <mengdong.lin@intel.com>
>
> Allow vendor drivers to define bespoke bytes ext handlers and IDs for TLV
> bytes controls. And the topology core will bind these handlers by matching
> IDs defined by the vendor driver and user space topology data file.
>
> Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
>
> diff --git a/include/sound/soc-topology.h b/include/sound/soc-topology.h
> index 865a141..3e412c6 100644
> --- a/include/sound/soc-topology.h
> +++ b/include/sound/soc-topology.h
> @@ -89,6 +89,13 @@ struct snd_soc_tplg_kcontrol_ops {
> struct snd_ctl_elem_info *uinfo);
> };
>
> +/* Bytes ext operations, for TLV byte controls */ struct
> +snd_soc_tplg_bytes_ext_ops {
> + u32 id;
> + int (*get)(unsigned int __user *bytes, unsigned int size);
> + int (*put)(const unsigned int __user *bytes, unsigned int size); };
> +
> /*
> * DAPM widget event handlers - used to map handlers onto widgets.
> */
> @@ -139,6 +146,10 @@ struct snd_soc_tplg_ops {
> /* bespoke kcontrol handlers available for binding */
> const struct snd_soc_tplg_kcontrol_ops *io_ops;
> int io_ops_count;
> +
> + /* bespoke bytes ext handlers available for binding */
> + const struct snd_soc_tplg_bytes_ext_ops *bytes_ext_ops;
> + int bytes_ext_ops_count;
> };
>
> /* gets a pointer to data from the firmware block header */ diff --git
> a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index
> 607f98b..b5a2868 100644
> --- a/sound/soc/soc-topology.c
> +++ b/sound/soc/soc-topology.c
> @@ -70,6 +70,10 @@ struct soc_tplg {
> const struct snd_soc_tplg_kcontrol_ops *io_ops;
> int io_ops_count;
>
> + /* bespoke bytes ext handlers, for TLV bytes controls */
> + const struct snd_soc_tplg_bytes_ext_ops *bytes_ext_ops;
> + int bytes_ext_ops_count;
> +
> /* optional fw loading callbacks to component drivers */
> struct snd_soc_tplg_ops *ops;
> };
> @@ -513,6 +517,15 @@ static int soc_tplg_kcontrol_bind_io(struct
> snd_soc_tplg_ctl_hdr *hdr, {
> int i;
>
> + /* TLV bytes controls don't need get/put ops */
> + if (k->iface & SNDRV_CTL_ELEM_IFACE_MIXER
> + && k->access & SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE
> + && k->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK
> + && hdr->ops.info == SND_SOC_TPLG_CTL_BYTES) {
> + k->info = snd_soc_bytes_info_ext;
> + return 0;
> + }
> +
> /* try and map standard kcontrols handler first */
> for (i = 0; i < num_ops; i++) {
>
> @@ -547,6 +560,32 @@ static int soc_tplg_kcontrol_bind_io(struct
> snd_soc_tplg_ctl_hdr *hdr,
> return -EINVAL;
> }
>
> +/* bind bytes ext get/put handlers for TLV bytes controls */ static int
> +soc_tplg_bytes_ext_bind_io(struct soc_tplg *tplg,
> + struct snd_soc_tplg_io_ops *ops_id,
> + struct soc_bytes_ext *sbe)
> +{
> + const struct snd_soc_tplg_bytes_ext_ops *ops = tplg->bytes_ext_ops;
> + int num_ops = tplg->bytes_ext_ops_count;
> + int i;
> +
> + /* try bespoke handlers */
> + for (i = 0; i < num_ops; i++) {
> +
> + if (sbe->put == NULL && ops[i].id == ops_id->put)
> + sbe->put = ops[i].put;
> + if (sbe->get == NULL && ops[i].id == ops_id->get)
> + sbe->get = ops[i].get;
> + }
> +
> + /* bespoke handlers found ? */
> + if (sbe->put && sbe->get)
> + return 0;
> +
> + /* nothing to bind */
> + return -EINVAL;
> +}
> +
> /* bind a widgets to it's evnt handlers */ int
> snd_soc_tplg_widget_bind_event(struct snd_soc_dapm_widget *w,
> const struct snd_soc_tplg_widget_events *events, @@ -690,6
> +729,14 @@ static int soc_tplg_dbytes_create(struct soc_tplg *tplg, unsigned
> int count,
> continue;
> }
>
> + /* create any TLV data */
> + soc_tplg_create_tlv(tplg, &kc, &be->hdr);
> + /* map bytes ext io handlers for TLV bytes controls */
> + if (kc.access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
> + soc_tplg_bytes_ext_bind_io(tplg,
> + &be->ext_ops, sbe);
> + }
> +
> /* pass control to driver for optional further init */
> err = soc_tplg_init_kcontrol(tplg, &kc,
> (struct snd_soc_tplg_ctl_hdr *)be);
> @@ -1315,6 +1362,14 @@ static struct snd_kcontrol_new
> *soc_tplg_dapm_widget_dbytes_create(
> continue;
> }
>
> + /* create any TLV data */
> + soc_tplg_create_tlv(tplg, &kc[i], &be->hdr);
> + /* map bytes ext io handlers for TLV bytes controls */
> + if (kc[i].access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
> + soc_tplg_bytes_ext_bind_io(tplg,
> + &be->ext_ops, sbe);
> + }
> +
> /* pass control to driver for optional further init */
> err = soc_tplg_init_kcontrol(tplg, &kc[i],
> (struct snd_soc_tplg_ctl_hdr *)be);
> @@ -1736,6 +1791,8 @@ int snd_soc_tplg_component_load(struct
> snd_soc_component *comp,
> tplg.req_index = id;
> tplg.io_ops = ops->io_ops;
> tplg.io_ops_count = ops->io_ops_count;
> + tplg.bytes_ext_ops = ops->bytes_ext_ops;
> + tplg.bytes_ext_ops_count = ops->bytes_ext_ops_count;
>
> return soc_tplg_load(&tplg);
> }
> --
> 1.9.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: topology: Add support for TLV bytes control
2015-08-12 2:10 [PATCH] ASoC: topology: Add support for TLV bytes control mengdong.lin
2015-08-13 1:41 ` Lin, Mengdong
@ 2015-08-14 19:17 ` Mark Brown
2015-08-15 15:04 ` Lin, Mengdong
1 sibling, 1 reply; 6+ messages in thread
From: Mark Brown @ 2015-08-14 19:17 UTC (permalink / raw
To: mengdong.lin; +Cc: tiwai, alsa-devel, liam.r.girdwood
[-- Attachment #1.1: Type: text/plain, Size: 1791 bytes --]
On Wed, Aug 12, 2015 at 10:10:51AM +0800, mengdong.lin@intel.com wrote:
> Allow vendor drivers to define bespoke bytes ext handlers and IDs for
> TLV bytes controls. And the topology core will bind these handlers by
> matching IDs defined by the vendor driver and user space topology
> data file.
> @@ -513,6 +517,15 @@ static int soc_tplg_kcontrol_bind_io(struct snd_soc_tplg_ctl_hdr *hdr,
> {
> int i;
>
> + /* TLV bytes controls don't need get/put ops */
AFAICT it's actually the case that we're binding them later rather than
that the ops aren't needed. Isn't that what soc_tplg_bytes_ext_bind_io()
does?
> + if (k->iface & SNDRV_CTL_ELEM_IFACE_MIXER
> + && k->access & SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE
> + && k->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK
> + && hdr->ops.info == SND_SOC_TPLG_CTL_BYTES) {
> + k->info = snd_soc_bytes_info_ext;
> + return 0;
> + }
> +
I'm confused. What's special about TLV controls compared to other
controls, why are the existing bespoke handlers which get bound in this
function not sufficient and why don't we bind the TLV bespoke handlers
here?
Having two different classes of bespoke handlers like this both called
bespoke handlers seems like it's going to lead to problems - either
bringing the interfaces closer together or naming them in a way that
clarifies their meaning seems better. Instead of just calling them
"bespoke handlers" we should probably just call them handlers for
whatever kind of control they're for and probably bind them first rather
than second so we're doing more specific to less specific handling.
That way drivers can also have specific handling for things the topology
data didn't anticipate they'd need it for which seems like it might come
in handy.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: topology: Add support for TLV bytes control
2015-08-14 19:17 ` Mark Brown
@ 2015-08-15 15:04 ` Lin, Mengdong
2015-08-15 16:10 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: Lin, Mengdong @ 2015-08-15 15:04 UTC (permalink / raw
To: Mark Brown; +Cc: tiwai@suse.de, alsa-devel@alsa-project.org, Girdwood, Liam R
> -----Original Message-----
> From: Mark Brown [mailto:broonie@kernel.org]
> Sent: Saturday, August 15, 2015 3:18 AM
> To: Lin, Mengdong
> Cc: alsa-devel@alsa-project.org; tiwai@suse.de; Girdwood, Liam R
> Subject: Re: [PATCH] ASoC: topology: Add support for TLV bytes control
>
> On Wed, Aug 12, 2015 at 10:10:51AM +0800, mengdong.lin@intel.com wrote:
>
> > Allow vendor drivers to define bespoke bytes ext handlers and IDs for
> > TLV bytes controls. And the topology core will bind these handlers by
> > matching IDs defined by the vendor driver and user space topology data
> > file.
>
> > @@ -513,6 +517,15 @@ static int soc_tplg_kcontrol_bind_io(struct
> > snd_soc_tplg_ctl_hdr *hdr, {
> > int i;
> >
> > + /* TLV bytes controls don't need get/put ops */
>
> AFAICT it's actually the case that we're binding them later rather than that
> the ops aren't needed. Isn't that what soc_tplg_bytes_ext_bind_io() does?
>
> > + if (k->iface & SNDRV_CTL_ELEM_IFACE_MIXER
> > + && k->access & SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE
> > + && k->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK
> > + && hdr->ops.info == SND_SOC_TPLG_CTL_BYTES) {
> > + k->info = snd_soc_bytes_info_ext;
> > + return 0;
> > + }
> > +
>
> I'm confused. What's special about TLV controls compared to other controls,
> why are the existing bespoke handlers which get bound in this function not
> sufficient and why don't we bind the TLV bespoke handlers here?
Okay. I'll bind the TLV bespoke handlers here, and remove soc_tplg_bytes_ext_bind_io().
So all ops binding will be handled in a single function soc_tplg_kcontrol_bind_io().
> Having two different classes of bespoke handlers like this both called bespoke
> handlers seems like it's going to lead to problems - either bringing the
> interfaces closer together or naming them in a way that clarifies their
> meaning seems better. Instead of just calling them "bespoke handlers" we
> should probably just call them handlers for whatever kind of control they're
> for and probably bind them first rather than second so we're doing more
> specific to less specific handling.
> That way drivers can also have specific handling for things the topology data
> didn't anticipate they'd need it for which seems like it might come in handy.
Are you suggesting that we bind bespoke handlers at first and then the standard handlers?
Since the bespoke handlers means more vendor-specific handling that need to be taken care at first.
We add comments to explain these two different classes of bespoke handlers.
struct snd_soc_tplg_ops {
...
/* bespoke kcontrol handlers available for binding */
const struct snd_soc_tplg_kcontrol_ops *io_ops;
int io_ops_count;
/* bespoke bytes ext handlers available for binding */
const struct snd_soc_tplg_bytes_ext_ops *bytes_ext_ops;
int bytes_ext_ops_count;
};
Thanks
Mengdong
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: topology: Add support for TLV bytes control
2015-08-15 15:04 ` Lin, Mengdong
@ 2015-08-15 16:10 ` Mark Brown
2015-08-17 1:33 ` Lin, Mengdong
0 siblings, 1 reply; 6+ messages in thread
From: Mark Brown @ 2015-08-15 16:10 UTC (permalink / raw
To: Lin, Mengdong
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, Girdwood, Liam R
[-- Attachment #1.1: Type: text/plain, Size: 1295 bytes --]
On Sat, Aug 15, 2015 at 03:04:53PM +0000, Lin, Mengdong wrote:
> > -----Original Message-----
> > From: Mark Brown [mailto:broonie@kernel.org]
Please fix your mail client to word wrap within paragraphs, your
messages are quite hard to read. It also seems to be rewriting quoted
material :/
> > Having two different classes of bespoke handlers like this both called bespoke
> > handlers seems like it's going to lead to problems - either bringing the
> > interfaces closer together or naming them in a way that clarifies their
> > meaning seems better. Instead of just calling them "bespoke handlers" we
> > should probably just call them handlers for whatever kind of control they're
> > for and probably bind them first rather than second so we're doing more
> > specific to less specific handling.
> > That way drivers can also have specific handling for things the topology data
> > didn't anticipate they'd need it for which seems like it might come in handy.
> Are you suggesting that we bind bespoke handlers at first and then the
> standard handlers? Since the bespoke handlers means more
> vendor-specific handling that need to be taken care at first.
Yes, that's what I'm suggesting. Why would this mean any additional
work? Either things have custom handlers or they don't...
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: topology: Add support for TLV bytes control
2015-08-15 16:10 ` Mark Brown
@ 2015-08-17 1:33 ` Lin, Mengdong
0 siblings, 0 replies; 6+ messages in thread
From: Lin, Mengdong @ 2015-08-17 1:33 UTC (permalink / raw
To: Mark Brown; +Cc: tiwai@suse.de, alsa-devel@alsa-project.org, Girdwood, Liam R
> -----Original Message-----
> From: Mark Brown [mailto:broonie@kernel.org]
> Sent: Sunday, August 16, 2015 12:10 AM
> On Sat, Aug 15, 2015 at 03:04:53PM +0000, Lin, Mengdong wrote:
> > > -----Original Message-----
> > > From: Mark Brown [mailto:broonie@kernel.org]
>
> Please fix your mail client to word wrap within paragraphs, your messages are
> quite hard to read. It also seems to be rewriting quoted material :/
Okay. Sorry for the inconvenience.
> > > Having two different classes of bespoke handlers like this both
> > > called bespoke handlers seems like it's going to lead to problems -
> > > either bringing the interfaces closer together or naming them in a
> > > way that clarifies their meaning seems better. Instead of just
> > > calling them "bespoke handlers" we should probably just call them
> > > handlers for whatever kind of control they're for and probably bind
> > > them first rather than second so we're doing more specific to less specific
> handling.
> > > That way drivers can also have specific handling for things the
> > > topology data didn't anticipate they'd need it for which seems like it
> might come in handy.
>
> > Are you suggesting that we bind bespoke handlers at first and then the
> > standard handlers? Since the bespoke handlers means more
> > vendor-specific handling that need to be taken care at first.
>
> Yes, that's what I'm suggesting. Why would this mean any additional work?
> Either things have custom handlers or they don't...
Got it. Not additional work. I'll revise the patch.
Thanks
Mengdong
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-08-17 1:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-12 2:10 [PATCH] ASoC: topology: Add support for TLV bytes control mengdong.lin
2015-08-13 1:41 ` Lin, Mengdong
2015-08-14 19:17 ` Mark Brown
2015-08-15 15:04 ` Lin, Mengdong
2015-08-15 16:10 ` Mark Brown
2015-08-17 1:33 ` Lin, Mengdong
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.