[PATCH v3 0/2] dmaengine: Use named initializers for arrays of pci_device_id

[PATCH v3 0/2] dmaengine: Use named initializers for arrays of pci_device_id

[Uwe Kleine-König (The Capable Hub)]

Hello,

the objective of this patch series is to prepare drivers/dma for a
change of pci_device_id that requires all users to initialize
.driver_data by name. See
https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@baylibre.com/
for more details. (This is about platform_device_id, but I intend to do
that for pci_device_id in the same manner.)

v2 is available at
https://lore.kernel.org/dmaengine/cover.1781161455.git.ukleinek@kernel.org
.

Changes since then:

 - Rebase to current next
 - Add review tags by Frank Li and Andy Shevchenko
 - Fix commit log to talk about the right device_id type (i.e.
   pci_device_id and neither pnp nor platform) (partly found by Sashiko)

Note that Andy prefers the use of PCI_DEVICE_DATA() over PCI_VDEVICE() +
explicit .driver_data because the former is more compact and the
follow-up change to struct pci_device_id could be handled in the
definition of that macro. I disagree here, as the compactness is bought
with quite some magic in the #define once it handles the union, and
being explicit (and thus less compact) has its merits, too. Additionally
the affected drivers need an adaption anyhow in their probe function,
and switching both .probe() and the .id_table in a single patch seems
right to me. Because from my POV my subjective opinion is obviously the
right one, I didn't follow Andy's request.

Best regards
Uwe

Uwe Kleine-König (The Capable Hub) (2):
  dmaengine: hsu: Drop unused pci driver data
  dmaengine: Consistently define pci_device_ids using named initializers

 drivers/dma/amd/ptdma/ptdma-pci.c  |  4 ++--
 drivers/dma/dw-edma/dw-edma-pcie.c |  2 +-
 drivers/dma/dw/pci.c               | 22 +++++++++++-----------
 drivers/dma/hsu/pci.c              |  4 ++--
 drivers/dma/pch_dma.c              | 26 +++++++++++++-------------
 5 files changed, 29 insertions(+), 29 deletions(-)


base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
-- 
2.55.0.11.g153666a7d9bb

[PATCH v3 1/2] dmaengine: hsu: Drop unused pci driver data

[Uwe Kleine-König (The Capable Hub)]

The driver explicitly sets the .driver_data member of struct
pci_device_id to zero without relying on that value. Drop these unused
assignments.

This patch doesn't modify the compiled array, only its representation in
source form benefits. The former was confirmed with builds on x86 and
arm64.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
 drivers/dma/hsu/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/hsu/pci.c b/drivers/dma/hsu/pci.c
index 0fcc0c0c22fc..b42c9c0887a8 100644
--- a/drivers/dma/hsu/pci.c
+++ b/drivers/dma/hsu/pci.c
@@ -116,8 +116,8 @@ static int hsu_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 }
 
 static const struct pci_device_id hsu_pci_id_table[] = {
-	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MFLD_HSU_DMA), 0 },
-	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD_HSU_DMA), 0 },
+	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MFLD_HSU_DMA) },
+	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD_HSU_DMA) },
 	{ }
 };
 MODULE_DEVICE_TABLE(pci, hsu_pci_id_table);
-- 
2.55.0.11.g153666a7d9bb

[PATCH v3 2/2] dmaengine: Consistently define pci_device_ids using named initializers

[Uwe Kleine-König (The Capable Hub)]

The .driver_data member of the various struct pci_device_id arrays were
initialized by list expressions. This isn't easily readable if you're
not into PCI. Using named initializers is more explicit and thus easier
to parse.

While touching these arrays, unify the list terminators to be just an
empty struct with no trailing comma.

This change doesn't introduce changes to the compiled pci_device_id
arrays, which was confirmed using x86 and arm64 builds.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
 drivers/dma/amd/ptdma/ptdma-pci.c  |  4 ++--
 drivers/dma/dw-edma/dw-edma-pcie.c |  2 +-
 drivers/dma/dw/pci.c               | 22 +++++++++++-----------
 drivers/dma/pch_dma.c              | 26 +++++++++++++-------------
 4 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/dma/amd/ptdma/ptdma-pci.c b/drivers/dma/amd/ptdma/ptdma-pci.c
index 22739ff0c3c5..0b226bec950c 100644
--- a/drivers/dma/amd/ptdma/ptdma-pci.c
+++ b/drivers/dma/amd/ptdma/ptdma-pci.c
@@ -223,9 +223,9 @@ static const struct pt_dev_vdata dev_vdata[] = {
 };
 
 static const struct pci_device_id pt_pci_table[] = {
-	{ PCI_VDEVICE(AMD, 0x1498), (kernel_ulong_t)&dev_vdata[0] },
+	{ PCI_VDEVICE(AMD, 0x1498), .driver_data = (kernel_ulong_t)&dev_vdata[0] },
 	/* Last entry must be zero */
-	{ 0, }
+	{ }
 };
 MODULE_DEVICE_TABLE(pci, pt_pci_table);
 
diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index b34e1e45aeb3..6876a8532b08 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -563,7 +563,7 @@ static void dw_edma_pcie_remove(struct pci_dev *pdev)
 static const struct pci_device_id dw_edma_pcie_id_table[] = {
 	{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
 	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
-	  (kernel_ulong_t)&xilinx_mdb_data },
+	  .driver_data = (kernel_ulong_t)&xilinx_mdb_data },
 	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B00F),
 	  .driver_data = (kernel_ulong_t)&xilinx_cpm6_dma_data },
 	{ }
diff --git a/drivers/dma/dw/pci.c b/drivers/dma/dw/pci.c
index a3aae3d1c093..99565fab3565 100644
--- a/drivers/dma/dw/pci.c
+++ b/drivers/dma/dw/pci.c
@@ -98,29 +98,29 @@ static const struct dev_pm_ops dw_pci_dev_pm_ops = {
 
 static const struct pci_device_id dw_pci_id_table[] = {
 	/* Medfield (GPDMA) */
-	{ PCI_VDEVICE(INTEL, 0x0827), (kernel_ulong_t)&dw_dma_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x0827), .driver_data = (kernel_ulong_t)&dw_dma_chip_pdata },
 
 	/* BayTrail */
-	{ PCI_VDEVICE(INTEL, 0x0f06), (kernel_ulong_t)&dw_dma_chip_pdata },
-	{ PCI_VDEVICE(INTEL, 0x0f40), (kernel_ulong_t)&dw_dma_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x0f06), .driver_data = (kernel_ulong_t)&dw_dma_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x0f40), .driver_data = (kernel_ulong_t)&dw_dma_chip_pdata },
 
 	/* Merrifield */
-	{ PCI_VDEVICE(INTEL, 0x11a2), (kernel_ulong_t)&idma32_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x11a2), .driver_data = (kernel_ulong_t)&idma32_chip_pdata },
 
 	/* Braswell */
-	{ PCI_VDEVICE(INTEL, 0x2286), (kernel_ulong_t)&dw_dma_chip_pdata },
-	{ PCI_VDEVICE(INTEL, 0x22c0), (kernel_ulong_t)&dw_dma_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x2286), .driver_data = (kernel_ulong_t)&dw_dma_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x22c0), .driver_data = (kernel_ulong_t)&dw_dma_chip_pdata },
 
 	/* Elkhart Lake iDMA 32-bit (PSE DMA) */
-	{ PCI_VDEVICE(INTEL, 0x4bb4), (kernel_ulong_t)&xbar_chip_pdata },
-	{ PCI_VDEVICE(INTEL, 0x4bb5), (kernel_ulong_t)&xbar_chip_pdata },
-	{ PCI_VDEVICE(INTEL, 0x4bb6), (kernel_ulong_t)&xbar_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x4bb4), .driver_data = (kernel_ulong_t)&xbar_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x4bb5), .driver_data = (kernel_ulong_t)&xbar_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x4bb6), .driver_data = (kernel_ulong_t)&xbar_chip_pdata },
 
 	/* Haswell */
-	{ PCI_VDEVICE(INTEL, 0x9c60), (kernel_ulong_t)&dw_dma_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x9c60), .driver_data = (kernel_ulong_t)&dw_dma_chip_pdata },
 
 	/* Broadwell */
-	{ PCI_VDEVICE(INTEL, 0x9ce0), (kernel_ulong_t)&dw_dma_chip_pdata },
+	{ PCI_VDEVICE(INTEL, 0x9ce0), .driver_data = (kernel_ulong_t)&dw_dma_chip_pdata },
 
 	{ }
 };
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index bf805f1024f6..152939e7c6fd 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -956,19 +956,19 @@ static void pch_dma_remove(struct pci_dev *pdev)
 #define PCI_DEVICE_ID_ML7831_DMA2_4CH	0x8815
 
 static const struct pci_device_id pch_dma_id_table[] = {
-	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_8CH), 8 },
-	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH), 4 },
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA1_8CH), 8}, /* UART Video */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA2_8CH), 8}, /* PCMIF SPI */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA3_4CH), 4}, /* FPGA */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA4_12CH), 12}, /* I2S */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA1_4CH), 4}, /* UART */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA2_4CH), 4}, /* Video SPI */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA3_4CH), 4}, /* Security */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA4_4CH), 4}, /* FPGA */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA1_8CH), 8}, /* UART */
-	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA2_4CH), 4}, /* SPI */
-	{ 0, },
+	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_8CH), .driver_data = 8 },
+	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH), .driver_data = 4 },
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA1_8CH), .driver_data = 8 },		/* UART Video */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA2_8CH), .driver_data = 8 },		/* PCMIF SPI */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA3_4CH), .driver_data = 4 },		/* FPGA */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA4_12CH), .driver_data = 12 },	/* I2S */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA1_4CH), .driver_data = 4 },		/* UART */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA2_4CH), .driver_data = 4 },		/* Video SPI */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA3_4CH), .driver_data = 4 },		/* Security */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA4_4CH), .driver_data = 4 },		/* FPGA */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA1_8CH), .driver_data = 8 },		/* UART */
+	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA2_4CH), .driver_data = 4 },		/* SPI */
+	{ }
 };
 MODULE_DEVICE_TABLE(pci, pch_dma_id_table);
 
-- 
2.55.0.11.g153666a7d9bb

Re: [PATCH v3 2/2] dmaengine: Consistently define pci_device_ids using named initializers

[Andy Shevchenko]

On Mon, Jul 20, 2026 at 02:03:49PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> The .driver_data member of the various struct pci_device_id arrays were
> initialized by list expressions. This isn't easily readable if you're
> not into PCI. Using named initializers is more explicit and thus easier
> to parse.
> 
> While touching these arrays, unify the list terminators to be just an
> empty struct with no trailing comma.
> 
> This change doesn't introduce changes to the compiled pci_device_id
> arrays, which was confirmed using x86 and arm64 builds.

...

> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c

>  static const struct pci_device_id dw_edma_pcie_id_table[] = {
>  	{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
>  	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
> -	  (kernel_ulong_t)&xilinx_mdb_data },
> +	  .driver_data = (kernel_ulong_t)&xilinx_mdb_data },
>  	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B00F),
>  	  .driver_data = (kernel_ulong_t)&xilinx_cpm6_dma_data },

It's inconsistent and can use PCI_DEVICE_DATA() in all cases.

>  	{ }

...

> +++ b/drivers/dma/pch_dma.c

>  static const struct pci_device_id pch_dma_id_table[] = {
> -	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_8CH), 8 },
> -	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH), 4 },
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA1_8CH), 8}, /* UART Video */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA2_8CH), 8}, /* PCMIF SPI */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA3_4CH), 4}, /* FPGA */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA4_12CH), 12}, /* I2S */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA1_4CH), 4}, /* UART */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA2_4CH), 4}, /* Video SPI */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA3_4CH), 4}, /* Security */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA4_4CH), 4}, /* FPGA */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA1_8CH), 8}, /* UART */
> -	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA2_4CH), 4}, /* SPI */
> -	{ 0, },
> +	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_8CH), .driver_data = 8 },
> +	{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH), .driver_data = 4 },
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA1_8CH), .driver_data = 8 },		/* UART Video */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA2_8CH), .driver_data = 8 },		/* PCMIF SPI */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA3_4CH), .driver_data = 4 },		/* FPGA */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA4_12CH), .driver_data = 12 },	/* I2S */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA1_4CH), .driver_data = 4 },		/* UART */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA2_4CH), .driver_data = 4 },		/* Video SPI */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA3_4CH), .driver_data = 4 },		/* Security */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7223_DMA4_4CH), .driver_data = 4 },		/* FPGA */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA1_8CH), .driver_data = 8 },		/* UART */
> +	{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_DMA2_4CH), .driver_data = 4 },		/* SPI */
> +	{ }
>  };

And I'm still strongly against this churn, which also makes lines too long.

PCI_DEVICE_DATA() makes it condensed and moves the burden of any future
conversions to the macro without touching users again.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/2] dmaengine: Use named initializers for arrays of pci_device_id

[Andy Shevchenko]

On Mon, Jul 20, 2026 at 02:03:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello,
> 
> the objective of this patch series is to prepare drivers/dma for a
> change of pci_device_id that requires all users to initialize
> .driver_data by name. See
> https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@baylibre.com/
> for more details. (This is about platform_device_id, but I intend to do
> that for pci_device_id in the same manner.)
> 
> v2 is available at
> https://lore.kernel.org/dmaengine/cover.1781161455.git.ukleinek@kernel.org
> .
> 
> Changes since then:
> 
>  - Rebase to current next
>  - Add review tags by Frank Li and Andy Shevchenko
>  - Fix commit log to talk about the right device_id type (i.e.
>    pci_device_id and neither pnp nor platform) (partly found by Sashiko)
> 
> Note that Andy prefers the use of PCI_DEVICE_DATA() over PCI_VDEVICE() +
> explicit .driver_data because the former is more compact and the
> follow-up change to struct pci_device_id could be handled in the
> definition of that macro. I disagree here, as the compactness is bought
> with quite some magic in the #define once it handles the union, and
> being explicit (and thus less compact) has its merits, too. Additionally
> the affected drivers need an adaption anyhow in their probe function,
> and switching both .probe() and the .id_table in a single patch seems
> right to me. Because from my POV my subjective opinion is obviously the
> right one, I didn't follow Andy's request.

I think we have not enough understanding regarding implementation. I'm not sure
how the union will affect the change in the drivers. When each driver is going
to be changed to support whatever pointers you want (CFI) this won't affect the
ID table. and hence makes _less_ churn.

Do you have a Git repository to show an example of the road map of the changes
for, say, one single driver on your choice to see the difference between your
approach and my suggestion?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/2] dmaengine: Use named initializers for arrays of pci_device_id

[Uwe Kleine-König (The Capable Hub)]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

Hello Andy,

On Tue, Aug 11, 2026 at 04:45:01PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 20, 2026 at 02:03:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > the objective of this patch series is to prepare drivers/dma for a
> > change of pci_device_id that requires all users to initialize
> > .driver_data by name. See
> > https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@baylibre.com/
> > for more details. (This is about platform_device_id, but I intend to do
> > that for pci_device_id in the same manner.)
> > 
> > v2 is available at
> > https://lore.kernel.org/dmaengine/cover.1781161455.git.ukleinek@kernel.org
> > .
> > 
> > Changes since then:
> > 
> >  - Rebase to current next
> >  - Add review tags by Frank Li and Andy Shevchenko
> >  - Fix commit log to talk about the right device_id type (i.e.
> >    pci_device_id and neither pnp nor platform) (partly found by Sashiko)
> > 
> > Note that Andy prefers the use of PCI_DEVICE_DATA() over PCI_VDEVICE() +
> > explicit .driver_data because the former is more compact and the
> > follow-up change to struct pci_device_id could be handled in the
> > definition of that macro. I disagree here, as the compactness is bought
> > with quite some magic in the #define once it handles the union, and
> > being explicit (and thus less compact) has its merits, too. Additionally
> > the affected drivers need an adaption anyhow in their probe function,
> > and switching both .probe() and the .id_table in a single patch seems
> > right to me. Because from my POV my subjective opinion is obviously the
> > right one, I didn't follow Andy's request.
> 
> I think we have not enough understanding regarding implementation. I'm not sure
> how the union will affect the change in the drivers. When each driver is going
> to be changed to support whatever pointers you want (CFI) this won't affect the
> ID table. and hence makes _less_ churn.
> 
> Do you have a Git repository to show an example of the road map of the changes
> for, say, one single driver on your choice to see the difference between your
> approach and my suggestion?

No, but I think I explained it in enough detail at
https://lore.kernel.org/all/af7yKdRdDSJjkoIk@monoceros/ . If the
description there still provokes open questions, please ask (maybe in
that thread).

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]