qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
@ 2009-02-01 12:01 Blue Swirl
  2009-02-01 13:22 ` Stuart Brady
  0 siblings, 1 reply; 7+ messages in thread
From: Blue Swirl @ 2009-02-01 12:01 UTC (permalink / raw)
  To: qemu-devel

Revision: 6490
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6490
Author:   blueswir1
Date:     2009-02-01 12:01:04 +0000 (Sun, 01 Feb 2009)

Log Message:
-----------
Update #defines for PCI vendor and device IDs from OpenBIOS and Linux

Modified Paths:
--------------
    trunk/hw/grackle_pci.c
    trunk/hw/ne2000.c
    trunk/hw/openpic.c
    trunk/hw/pci.h
    trunk/hw/ppc_chrp.c
    trunk/hw/ppc_oldworld.c
    trunk/hw/unin_pci.c
    trunk/hw/vga.c

Modified: trunk/hw/grackle_pci.c
===================================================================
--- trunk/hw/grackle_pci.c	2009-01-30 20:39:41 UTC (rev 6489)
+++ trunk/hw/grackle_pci.c	2009-02-01 12:01:04 UTC (rev 6490)
@@ -154,10 +154,8 @@
 
 #if 0
     /* PCI2PCI bridge same values as PearPC - check this */
-    d->config[0x00] = 0x11; // vendor_id
-    d->config[0x01] = 0x10;
-    d->config[0x02] = 0x26; // device_id
-    d->config[0x03] = 0x00;
+    pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_DEC);
+    pci_config_set_device_id(d->config, PCI_DEVICE_ID_DEC_21154);
     d->config[0x08] = 0x02; // revision
     d->config[0x0a] = 0x04; // class_sub = pci2pci
     d->config[0x0b] = 0x06; // class_base = PCI_bridge

Modified: trunk/hw/ne2000.c
===================================================================
--- trunk/hw/ne2000.c	2009-01-30 20:39:41 UTC (rev 6489)
+++ trunk/hw/ne2000.c	2009-02-01 12:01:04 UTC (rev 6490)
@@ -791,7 +791,7 @@
                                               NULL, NULL);
     pci_conf = d->dev.config;
     pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_REALTEK);
-    pci_config_set_device_id(pci_conf, 0x8029); // Realtek 8029
+    pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_REALTEK_RTL8029);
     pci_conf[0x0a] = 0x00; // ethernet network controller
     pci_conf[0x0b] = 0x02;
     pci_conf[0x0e] = 0x00; // header_type

Modified: trunk/hw/openpic.c
===================================================================
--- trunk/hw/openpic.c	2009-01-30 20:39:41 UTC (rev 6489)
+++ trunk/hw/openpic.c	2009-02-01 12:01:04 UTC (rev 6490)
@@ -1018,7 +1018,7 @@
             return NULL;
         pci_conf = opp->pci_dev.config;
         pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_IBM);
-        pci_config_set_device_id(pci_conf, 0xffff); // MPIC2
+        pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_IBM_OPENPIC2);
         pci_conf[0x0a] = 0x80; // PIC
         pci_conf[0x0b] = 0x08;
         pci_conf[0x0e] = 0x00; // header_type

Modified: trunk/hw/pci.h
===================================================================
--- trunk/hw/pci.h	2009-01-30 20:39:41 UTC (rev 6489)
+++ trunk/hw/pci.h	2009-02-01 12:01:04 UTC (rev 6490)
@@ -12,10 +12,12 @@
 #define PCI_DEVICE_ID_LSI_53C895A        0x0012
 
 #define PCI_VENDOR_ID_DEC                0x1011
+#define PCI_DEVICE_ID_DEC_21154          0x0026
 
 #define PCI_VENDOR_ID_CIRRUS             0x1013
 
 #define PCI_VENDOR_ID_IBM                0x1014
+#define PCI_DEVICE_ID_IBM_OPENPIC2       0xffff
 
 #define PCI_VENDOR_ID_AMD                0x1022
 #define PCI_DEVICE_ID_AMD_LANCE          0x2000
@@ -27,7 +29,11 @@
 #define PCI_DEVICE_ID_MOTOROLA_RAVEN     0x4801
 
 #define PCI_VENDOR_ID_APPLE              0x106b
+#define PCI_DEVICE_ID_APPLE_343S1201     0x0010
+#define PCI_DEVICE_ID_APPLE_UNI_N_I_PCI  0x001e
+#define PCI_DEVICE_ID_APPLE_UNI_N_PCI    0x001f
 #define PCI_DEVICE_ID_APPLE_UNI_N_AGP    0x0020
+#define PCI_DEVICE_ID_APPLE_UNI_N_KEYL   0x0022
 
 #define PCI_VENDOR_ID_SUN                0x108e
 #define PCI_DEVICE_ID_SUN_EBUS           0x1000
@@ -38,12 +44,16 @@
 #define PCI_DEVICE_ID_CMD_646            0x0646
 
 #define PCI_VENDOR_ID_REALTEK            0x10ec
+#define PCI_DEVICE_ID_REALTEK_RTL8029    0x8029
 #define PCI_DEVICE_ID_REALTEK_8139       0x8139
 
 #define PCI_VENDOR_ID_XILINX             0x10ee
 
 #define PCI_VENDOR_ID_MARVELL            0x11ab
 
+#define PCI_VENDOR_ID_QEMU               0x1234
+#define PCI_DEVICE_ID_QEMU_VGA           0x1111
+
 #define PCI_VENDOR_ID_ENSONIQ            0x1274
 #define PCI_DEVICE_ID_ENSONIQ_ES1370     0x5000
 

Modified: trunk/hw/ppc_chrp.c
===================================================================
--- trunk/hw/ppc_chrp.c	2009-01-30 20:39:41 UTC (rev 6489)
+++ trunk/hw/ppc_chrp.c	2009-02-01 12:01:04 UTC (rev 6490)
@@ -296,8 +296,9 @@
     adb_mouse_init(&adb_bus);
 
 
-    macio_init(pci_bus, 0x0022, 0, pic_mem_index, dbdma_mem_index,
-               cuda_mem_index, NULL, 2, ide_mem_index, escc_mem_index);
+    macio_init(pci_bus, PCI_DEVICE_ID_APPLE_UNI_N_KEYL, 0, pic_mem_index,
+               dbdma_mem_index, cuda_mem_index, NULL, 2, ide_mem_index,
+               escc_mem_index);
 
     if (usb_enabled) {
         usb_ohci_init_pci(pci_bus, 3, -1);

Modified: trunk/hw/ppc_oldworld.c
===================================================================
--- trunk/hw/ppc_oldworld.c	2009-01-30 20:39:41 UTC (rev 6489)
+++ trunk/hw/ppc_oldworld.c	2009-02-01 12:01:04 UTC (rev 6490)
@@ -360,8 +360,9 @@
     nvr = macio_nvram_init(&nvram_mem_index, 0x2000);
     pmac_format_nvram_partition(nvr, 0x2000);
 
-    macio_init(pci_bus, 0x0010, 1, pic_mem_index, dbdma_mem_index,
-               cuda_mem_index, nvr, 2, ide_mem_index, escc_mem_index);
+    macio_init(pci_bus, PCI_DEVICE_ID_APPLE_343S1201, 1, pic_mem_index,
+               dbdma_mem_index, cuda_mem_index, nvr, 2, ide_mem_index,
+               escc_mem_index);
 
     if (usb_enabled) {
         usb_ohci_init_pci(pci_bus, 3, -1);

Modified: trunk/hw/unin_pci.c
===================================================================
--- trunk/hw/unin_pci.c	2009-01-30 20:39:41 UTC (rev 6489)
+++ trunk/hw/unin_pci.c	2009-02-01 12:01:04 UTC (rev 6490)
@@ -175,7 +175,7 @@
     d = pci_register_device(s->bus, "Uni-north main", sizeof(PCIDevice),
                             11 << 3, NULL, NULL);
     pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_APPLE);
-    pci_config_set_device_id(d->config, 0x001f); // device_id
+    pci_config_set_device_id(d->config, PCI_DEVICE_ID_APPLE_UNI_N_PCI);
     d->config[0x08] = 0x00; // revision
     d->config[0x0A] = 0x00; // class_sub = pci host
     d->config[0x0B] = 0x06; // class_base = PCI_bridge
@@ -188,8 +188,8 @@
     /* pci-to-pci bridge */
     d = pci_register_device("Uni-north bridge", sizeof(PCIDevice), 0, 13 << 3,
                             NULL, NULL);
-    pci_config_set_vendor_id(d->config, 0x1011); // vendor_id : TI
-    pci_config_set_device_id(d->config, 0x0026); // device_id
+    pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_DEC);
+    pci_config_set_device_id(d->config, PCI_DEVICE_ID_DEC_21154);
     d->config[0x08] = 0x05; // revision
     d->config[0x0A] = 0x04; // class_sub = pci2pci
     d->config[0x0B] = 0x06; // class_base = PCI_bridge
@@ -249,7 +249,7 @@
     d = pci_register_device("Uni-north internal", sizeof(PCIDevice),
                             3, 11 << 3, NULL, NULL);
     pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_APPLE);
-    pci_config_set_device_id(d->config, 0x001E); // device_id
+    pci_config_set_device_id(d->config, PCI_DEVICE_ID_APPLE_UNI_N_I_PCI);
     d->config[0x08] = 0x00; // revision
     d->config[0x0A] = 0x00; // class_sub = pci host
     d->config[0x0B] = 0x06; // class_base = PCI_bridge

Modified: trunk/hw/vga.c
===================================================================
--- trunk/hw/vga.c	2009-01-30 20:39:41 UTC (rev 6489)
+++ trunk/hw/vga.c	2009-02-01 12:01:04 UTC (rev 6490)
@@ -2510,8 +2510,9 @@
     s->pci_dev = &d->dev;
 
     pci_conf = d->dev.config;
-    pci_config_set_vendor_id(pci_conf, 0x1234); // dummy VGA (same as Bochs ID)
-    pci_config_set_device_id(pci_conf, 0x1111);
+    // dummy VGA (same as Bochs ID)
+    pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_QEMU);
+    pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_QEMU_VGA);
     pci_conf[0x0a] = 0x00; // VGA controller
     pci_conf[0x0b] = 0x03;
     pci_conf[0x0e] = 0x00; // header_type

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
  2009-02-01 12:01 [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux Blue Swirl
@ 2009-02-01 13:22 ` Stuart Brady
  2009-02-01 14:39   ` Blue Swirl
  0 siblings, 1 reply; 7+ messages in thread
From: Stuart Brady @ 2009-02-01 13:22 UTC (permalink / raw)
  To: qemu-devel

On Sun, Feb 01, 2009 at 12:01:07PM +0000, Blue Swirl wrote:
> Update #defines for PCI vendor and device IDs from OpenBIOS and Linux

Just a few questions...

> Modified: trunk/hw/grackle_pci.c
> ===================================================================
> --- trunk/hw/grackle_pci.c	2009-01-30 20:39:41 UTC (rev 6489)
> +++ trunk/hw/grackle_pci.c	2009-02-01 12:01:04 UTC (rev 6490)
> @@ -154,10 +154,8 @@
>  
>  #if 0
>      /* PCI2PCI bridge same values as PearPC - check this */
> -    d->config[0x00] = 0x11; // vendor_id
> -    d->config[0x01] = 0x10;
> -    d->config[0x02] = 0x26; // device_id
> -    d->config[0x03] = 0x00;
> +    pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_DEC);
> +    pci_config_set_device_id(d->config, PCI_DEVICE_ID_DEC_21154);

Isn't the DEC 21154 is a Tulip-compatible NIC, and not a PCI bridge?
Yes, 0x1011 is the Vendor ID for DEC, and 0x0026 is the Device ID for
the 21154, but what was actually intended here?

> +#define PCI_DEVICE_ID_IBM_OPENPIC2       0xffff
> +#define PCI_DEVICE_ID_APPLE_343S1201     0x0010
> +#define PCI_DEVICE_ID_APPLE_UNI_N_I_PCI  0x001e
> +#define PCI_DEVICE_ID_APPLE_UNI_N_PCI    0x001f
> +#define PCI_DEVICE_ID_APPLE_UNI_N_KEYL   0x0022
> +#define PCI_DEVICE_ID_REALTEK_RTL8029    0x8029
>  #define PCI_DEVICE_ID_REALTEK_8139       0x8139

It probably wouldn't hurt to mark IDs without a corresponding definition
in Linux's pci_ids.h with a comment...  (Also, RTL8029 vs. 8139?...)

> +#define PCI_VENDOR_ID_QEMU               0x1234
> +#define PCI_DEVICE_ID_QEMU_VGA           0x1111

I gather 0x1234/0x1111 was originally chosen by Bochs.  Unfortunately,
it is apparently allocated to 'Technical Corp.'  Would it be possible
to use something less confusing instead?

Cheers,
-- 
Stuart Brady

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
  2009-02-01 13:22 ` Stuart Brady
@ 2009-02-01 14:39   ` Blue Swirl
  2009-02-01 15:16     ` Stuart Brady
  0 siblings, 1 reply; 7+ messages in thread
From: Blue Swirl @ 2009-02-01 14:39 UTC (permalink / raw)
  To: qemu-devel

On 2/1/09, Stuart Brady <sdbrady@ntlworld.com> wrote:
> On Sun, Feb 01, 2009 at 12:01:07PM +0000, Blue Swirl wrote:
>  > Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
>
>
> Just a few questions...
>
>
>  > Modified: trunk/hw/grackle_pci.c
>  > ===================================================================
>  > --- trunk/hw/grackle_pci.c    2009-01-30 20:39:41 UTC (rev 6489)
>  > +++ trunk/hw/grackle_pci.c    2009-02-01 12:01:04 UTC (rev 6490)
>  > @@ -154,10 +154,8 @@
>  >
>  >  #if 0
>  >      /* PCI2PCI bridge same values as PearPC - check this */
>  > -    d->config[0x00] = 0x11; // vendor_id
>  > -    d->config[0x01] = 0x10;
>  > -    d->config[0x02] = 0x26; // device_id
>  > -    d->config[0x03] = 0x00;
>  > +    pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_DEC);
>  > +    pci_config_set_device_id(d->config, PCI_DEVICE_ID_DEC_21154);
>
>
> Isn't the DEC 21154 is a Tulip-compatible NIC, and not a PCI bridge?
>  Yes, 0x1011 is the Vendor ID for DEC, and 0x0026 is the Device ID for
>  the 21154, but what was actually intended here?

I'd rather guess it's a PCI bridge.

>  > +#define PCI_DEVICE_ID_IBM_OPENPIC2       0xffff
>
> > +#define PCI_DEVICE_ID_APPLE_343S1201     0x0010
>  > +#define PCI_DEVICE_ID_APPLE_UNI_N_I_PCI  0x001e
>  > +#define PCI_DEVICE_ID_APPLE_UNI_N_PCI    0x001f
>
> > +#define PCI_DEVICE_ID_APPLE_UNI_N_KEYL   0x0022
>
> > +#define PCI_DEVICE_ID_REALTEK_RTL8029    0x8029
>  >  #define PCI_DEVICE_ID_REALTEK_8139       0x8139
>
>
> It probably wouldn't hurt to mark IDs without a corresponding definition
>  in Linux's pci_ids.h with a comment...  (Also, RTL8029 vs. 8139?...)

That's what ne2k uses (not 8139).

>  > +#define PCI_VENDOR_ID_QEMU               0x1234
>  > +#define PCI_DEVICE_ID_QEMU_VGA           0x1111
>
>
> I gather 0x1234/0x1111 was originally chosen by Bochs.  Unfortunately,
>  it is apparently allocated to 'Technical Corp.'  Would it be possible
>  to use something less confusing instead?

The IDs could be replaced with some real, original VGA compatible PCI
card, without any extra features. Bochs extensions should probably be
disabled then. Any suggestions?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
  2009-02-01 14:39   ` Blue Swirl
@ 2009-02-01 15:16     ` Stuart Brady
  2009-02-01 15:42       ` Blue Swirl
  2009-02-02 10:23       ` Gerd Hoffmann
  0 siblings, 2 replies; 7+ messages in thread
From: Stuart Brady @ 2009-02-01 15:16 UTC (permalink / raw)
  To: qemu-devel; +Cc: Gerd Hoffmann

On Sun, Feb 01, 2009 at 04:39:55PM +0200, Blue Swirl wrote:
> On 2/1/09, Stuart Brady <sdbrady@ntlworld.com> wrote:
> > Isn't the DEC 21154 is a Tulip-compatible NIC, and not a PCI bridge?
> 
> I'd rather guess it's a PCI bridge.

Seems I got a bit mixed up, there!

> > > +#define PCI_DEVICE_ID_REALTEK_RTL8029    0x8029
> > >  #define PCI_DEVICE_ID_REALTEK_8139       0x8139
> >
> > (Also, RTL8029 vs. 8139?...)
> 
> That's what ne2k uses (not 8139).

Sorry, I wasn't clear -- I was just pointing at the naming i.e. RTL8029
as opposed to just 8029, but wasn't trying to make a big deal out of it.

> > I gather 0x1234/0x1111 was originally chosen by Bochs.  Unfortunately,
> > it is apparently allocated to 'Technical Corp.'  Would it be possible
> > to use something less confusing instead?
> 
> The IDs could be replaced with some real, original VGA compatible PCI
> card, without any extra features. Bochs extensions should probably be
> disabled then. Any suggestions?

Not sure... perhaps Gerd could help, here? :)

(BTW, I notice that OpenBIOS/PPC depends on this particular ID, and I
wonder if Bochs BIOS would have to be updated, too.)

Cheers,
-- 
Stuart Brady

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
  2009-02-01 15:16     ` Stuart Brady
@ 2009-02-01 15:42       ` Blue Swirl
  2009-02-01 18:03         ` Volker Ruppert
  2009-02-02 10:23       ` Gerd Hoffmann
  1 sibling, 1 reply; 7+ messages in thread
From: Blue Swirl @ 2009-02-01 15:42 UTC (permalink / raw)
  To: qemu-devel

On 2/1/09, Stuart Brady <sdbrady@ntlworld.com> wrote:
> On Sun, Feb 01, 2009 at 04:39:55PM +0200, Blue Swirl wrote:
>  > On 2/1/09, Stuart Brady <sdbrady@ntlworld.com> wrote:
>
> > > Isn't the DEC 21154 is a Tulip-compatible NIC, and not a PCI bridge?
>  >
>
> > I'd rather guess it's a PCI bridge.
>
>
> Seems I got a bit mixed up, there!
>
>
>  > > > +#define PCI_DEVICE_ID_REALTEK_RTL8029    0x8029
>  > > >  #define PCI_DEVICE_ID_REALTEK_8139       0x8139
>  > >
>
> > > (Also, RTL8029 vs. 8139?...)
>  >
>  > That's what ne2k uses (not 8139).
>
>
> Sorry, I wasn't clear -- I was just pointing at the naming i.e. RTL8029
>  as opposed to just 8029, but wasn't trying to make a big deal out of it.
>
>
>  > > I gather 0x1234/0x1111 was originally chosen by Bochs.  Unfortunately,
>  > > it is apparently allocated to 'Technical Corp.'  Would it be possible
>  > > to use something less confusing instead?
>  >
>  > The IDs could be replaced with some real, original VGA compatible PCI
>  > card, without any extra features. Bochs extensions should probably be
>  > disabled then. Any suggestions?
>
>
> Not sure... perhaps Gerd could help, here? :)
>
>  (BTW, I notice that OpenBIOS/PPC depends on this particular ID, and I
>  wonder if Bochs BIOS would have to be updated, too.)

Of course some coordinated changed would be required, if we even want to do it.

At least here is one check:
http://bochs.sourceforge.net/cgi-bin/lxr/source/bios/rombios32.c#L700

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
  2009-02-01 15:42       ` Blue Swirl
@ 2009-02-01 18:03         ` Volker Ruppert
  0 siblings, 0 replies; 7+ messages in thread
From: Volker Ruppert @ 2009-02-01 18:03 UTC (permalink / raw)
  To: qemu-devel

Hi all!

> >  (BTW, I notice that OpenBIOS/PPC depends on this particular ID, and I
> >  wonder if Bochs BIOS would have to be updated, too.)
>
> Of course some coordinated changed would be required, if we even want to do
> it.
>
> At least here is one check:
> http://bochs.sourceforge.net/cgi-bin/lxr/source/bios/rombios32.c#L700

Don't forget about the VGABIOS. The latest CVS version reads the LFB base from 
PCI using the vendor ID 0x1234. We should keep the Bochs VBE until we are 
able to implement modern graphics hardware. In the meantime we could switch 
to a really unused PCI vendor ID.

--
Thanks

Volker

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
  2009-02-01 15:16     ` Stuart Brady
  2009-02-01 15:42       ` Blue Swirl
@ 2009-02-02 10:23       ` Gerd Hoffmann
  1 sibling, 0 replies; 7+ messages in thread
From: Gerd Hoffmann @ 2009-02-02 10:23 UTC (permalink / raw)
  To: Stuart Brady; +Cc: qemu-devel

>>>> +#define PCI_DEVICE_ID_REALTEK_RTL8029    0x8029
>>>>  #define PCI_DEVICE_ID_REALTEK_8139       0x8139
>>> (Also, RTL8029 vs. 8139?...)
>> That's what ne2k uses (not 8139).
> 
> Sorry, I wasn't clear -- I was just pointing at the naming i.e. RTL8029
> as opposed to just 8029, but wasn't trying to make a big deal out of it.

REALTEK_RTL is somewhat redundant, I'd drop the RTL from the 8029 ...

>>> I gather 0x1234/0x1111 was originally chosen by Bochs.  Unfortunately,
>>> it is apparently allocated to 'Technical Corp.'  Would it be possible
>>> to use something less confusing instead?
>> The IDs could be replaced with some real, original VGA compatible PCI
>> card, without any extra features. Bochs extensions should probably be
>> disabled then. Any suggestions?

Well, you probably have a hard time to find a real VGA card *with* PCI
and *without* extra features.

> Not sure... perhaps Gerd could help, here? :)

I can talk to our PCI guy, shouldn't be a big issue to get an ID for the
qemu std vga.  Thats certainly better that some random ID grabbed.

cheers,
  Gerd

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2009-02-02 10:23 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-01 12:01 [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux Blue Swirl
2009-02-01 13:22 ` Stuart Brady
2009-02-01 14:39   ` Blue Swirl
2009-02-01 15:16     ` Stuart Brady
2009-02-01 15:42       ` Blue Swirl
2009-02-01 18:03         ` Volker Ruppert
2009-02-02 10:23       ` Gerd Hoffmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).