public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2.6] Altix updates
@ 2004-01-15 21:54 Pat Gefre
  2004-01-16  2:34 ` Andrew Morton
  2004-01-16 14:41 ` Christoph Hellwig
  0 siblings, 2 replies; 11+ messages in thread
From: Pat Gefre @ 2004-01-15 21:54 UTC (permalink / raw)
  To: akpm, davidm; +Cc: linux-kernel, hch

My latest set of patches for 2.6 Altix is at:
ftp://oss.sgi.com/projects/sn2/sn2-update/

diffstats are at the end of this email.

The reorg patch is one that I had submitted in the last set - it was
decided to take out the renaming, which I did.

-- Pat

Patrick Gefre
Silicon Graphics, Inc.                     (E-Mail)  pfg@sgi.com
2750 Blue Water Rd                         (Voice)   (651) 683-3127
Eagan, MN 55121-1400                       (FAX)     (651) 683-3054





001-reorg.patch
 arch/ia64/sn/io/machvec/pci_bus_cvlink.c |  358 ++-----
 arch/ia64/sn/io/machvec/pci_dma.c        |   19 
 arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c    |  355 ------
 arch/ia64/sn/io/sn2/pcibr/pcibr_config.c |   53 -
 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c    | 1582 +++----------------------------
 arch/ia64/sn/io/sn2/pcibr/pcibr_error.c  |  690 ++++++++-----
 arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c   |  289 +----
 arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c    |  288 +++--
 arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c   |  265 ++---
 arch/ia64/sn/io/sn2/pciio.c              |   33 
 arch/ia64/sn/io/sn2/pic.c                |  588 +++++++++++
 arch/ia64/sn/kernel/irq.c                |    6 
 include/asm-ia64/sn/module.h             |    9 
 include/asm-ia64/sn/pci/bridge.h         |    8 
 include/asm-ia64/sn/pci/pci_bus_cvlink.h |    7 
 include/asm-ia64/sn/pci/pcibr.h          |   47 
 include/asm-ia64/sn/pci/pcibr_private.h  |  142 ++
 include/asm-ia64/sn/pci/pciio.h          |   25 
 include/asm-ia64/sn/pci/pic.h            |  809 ++-------------
 include/asm-ia64/sn/sn2/intr.h           |    4 
 20 files changed, 2011 insertions(+), 3566 deletions(-)


002-reorg1.patch
 pcibr_reg.c | 1437 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 1426 insertions(+), 11 deletions(-)


003-misc.cleanup.patch
 arch/ia64/sn/io/io.c                    |   42 ++++++++--------
 arch/ia64/sn/io/sn2/ml_iograph.c        |    7 +-
 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c   |   38 ++++++--------
 arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c |    7 +-
 arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c  |    8 +--
 arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c   |   12 ++--
 arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c  |   82 ++++++++++++++++----------------
 arch/ia64/sn/io/sn2/pciio.c             |   12 +---
 arch/ia64/sn/io/sn2/pic.c               |    6 +-
 arch/ia64/sn/io/sn2/shuberror.c         |    1 
 arch/ia64/sn/io/sn2/xbow.c              |    4 +
 arch/ia64/sn/io/sn2/xtalk.c             |   18 ++-----
 arch/ia64/sn/io/xswitch.c               |   10 ++-
 arch/ia64/sn/kernel/bte.c               |    2 
 arch/ia64/sn/kernel/mca.c               |    1 
 arch/ia64/sn/kernel/probe.c             |    1 
 arch/ia64/sn/kernel/sn2/prominfo_proc.c |    1 
 arch/ia64/sn/kernel/sn2/sn2_smp.c       |    1 
 arch/ia64/sn/kernel/sn2/sn_proc_fs.c    |    1 
 drivers/char/sn_serial.c                |    1 
 include/asm-ia64/sn/addrs.h             |    4 -
 include/asm-ia64/sn/alenlist.h          |   18 +++----
 include/asm-ia64/sn/arch.h              |    7 --
 include/asm-ia64/sn/bte.h               |    3 -
 include/asm-ia64/sn/clksupport.h        |    2 
 include/asm-ia64/sn/driver.h            |    2 
 include/asm-ia64/sn/hcl.h               |    2 
 include/asm-ia64/sn/hcl_util.h          |    2 
 include/asm-ia64/sn/hwgfs.h             |    3 +
 include/asm-ia64/sn/iograph.h           |    1 
 include/asm-ia64/sn/klconfig.h          |    8 +--
 include/asm-ia64/sn/kldir.h             |    4 -
 include/asm-ia64/sn/module.h            |    2 
 include/asm-ia64/sn/nodepda.h           |    4 -
 include/asm-ia64/sn/pci/bridge.h        |   16 +++---
 include/asm-ia64/sn/pci/pcibr_private.h |   15 -----
 include/asm-ia64/sn/pci/pciio.h         |   20 +++----
 include/asm-ia64/sn/pci/pciio_private.h |    6 +-
 include/asm-ia64/sn/pda.h               |    3 -
 include/asm-ia64/sn/pio.h               |    6 --
 include/asm-ia64/sn/sgi.h               |   17 +++++-
 include/asm-ia64/sn/sn2/arch.h          |    3 -
 include/asm-ia64/sn/sn2/sn_private.h    |   12 +---
 include/asm-ia64/sn/sn_cpuid.h          |    6 --
 include/asm-ia64/sn/sn_private.h        |    5 -
 include/asm-ia64/sn/types.h             |    8 ---
 include/asm-ia64/sn/vector.h            |    2 
 include/asm-ia64/sn/xtalk/xbow.h        |   19 -------
 include/asm-ia64/sn/xtalk/xtalk.h       |   16 +++---
 include/asm-ia64/sn/xtalk/xwidget.h     |   26 +++++-----
 50 files changed, 230 insertions(+), 267 deletions(-)


004-misc.cleanup1.patch
 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c   |    2 ++
 include/asm-ia64/sn/pci/pcibr_private.h |   10 +++++-----
 2 files changed, 7 insertions(+), 5 deletions(-)


005-ate.flags.patch
 arch/ia64/sn/io/machvec/pci_dma.c |    8 ++++++--
 include/asm-ia64/sn/pci/pcibr.h   |    6 ++++++
 2 files changed, 12 insertions(+), 2 deletions(-)


006-find_lboard.patch
 arch/ia64/sn/io/platform_init/sgi_io_init.c |    2 
 arch/ia64/sn/io/sn2/klconflib.c             |  215 +++++++---------------------
 arch/ia64/sn/io/sn2/klgraph.c               |   87 +----------
 arch/ia64/sn/io/sn2/ml_iograph.c            |   13 -
 arch/ia64/sn/io/sn2/module.c                |   37 ++++
 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c       |   14 +
 arch/ia64/sn/kernel/setup.c                 |   35 ++++
 include/asm-ia64/sn/klconfig.h              |    7 
 8 files changed, 153 insertions(+), 257 deletions(-)


007-ate.patch
 pcibr_ate.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)


008-early_probe_for_widget.patch
 ml_iograph.c |   29 ++++++++++++++---------------
 1 files changed, 14 insertions(+), 15 deletions(-)


009-setup.c.patch
 setup.c |   89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
 1 files changed, 76 insertions(+), 13 deletions(-)


010-kill-pcibr_intr_func.patch
 pcibr_intr.c |  136 -----------------------------------------------------------
 1 files changed, 2 insertions(+), 134 deletions(-)


011-irq.update.patch
 irq.c |  161 +++++++++++++++++++++++-------------------------------------------
 1 files changed, 58 insertions(+), 103 deletions(-)


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

* Re: [PATCH 2.6] Altix updates
  2004-01-15 21:54 [PATCH 2.6] Altix updates Pat Gefre
@ 2004-01-16  2:34 ` Andrew Morton
  2004-01-16 14:41 ` Christoph Hellwig
  1 sibling, 0 replies; 11+ messages in thread
From: Andrew Morton @ 2004-01-16  2:34 UTC (permalink / raw)
  To: Pat Gefre; +Cc: davidm, linux-kernel, hch

Pat Gefre <pfg@sgi.com> wrote:
>
>  My latest set of patches for 2.6 Altix is at:
>  ftp://oss.sgi.com/projects/sn2/sn2-update/

I'll assume these are for review at this time.

When that is complete, please send them over, one changelog+patch per email
in the time-honoured manner, thanks.


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

* Re: [PATCH 2.6] Altix updates
  2004-01-15 21:54 [PATCH 2.6] Altix updates Pat Gefre
  2004-01-16  2:34 ` Andrew Morton
@ 2004-01-16 14:41 ` Christoph Hellwig
  2004-01-20 17:50   ` Patrick Gefre
  1 sibling, 1 reply; 11+ messages in thread
From: Christoph Hellwig @ 2004-01-16 14:41 UTC (permalink / raw)
  To: Pat Gefre; +Cc: akpm, davidm, linux-kernel, hch

On Thu, Jan 15, 2004 at 03:54:37PM -0600, Pat Gefre wrote:
> 001-reorg.patch
> 002-reorg1.patch

The IS_IOADDR() stuff in the accesor funcs in pcibr_reg.c is completly
bogus, please decide whether you want to pass a pointer to the pcibr_soft
or bridge_t to it instead of doing second-guessing.

Also while the pic.h changes look okay they will conflict with a patch
I'm about to send that adds common headers for the bridge/xbow/xwidget
register for mips and IA64.  Can you send me a version of pic.h with
those changes and the big endian ifdefs back in so I can just incorporate
the new version into my patch?

Also are all those access you abstract away different in TIOCP?  If not
please don't add the wrappers for them.


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

* Re: [PATCH 2.6] Altix updates
  2004-01-16 14:41 ` Christoph Hellwig
@ 2004-01-20 17:50   ` Patrick Gefre
  2004-01-20 18:08     ` Christoph Hellwig
  0 siblings, 1 reply; 11+ messages in thread
From: Patrick Gefre @ 2004-01-20 17:50 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: akpm, davidm, linux-kernel

Christoph Hellwig wrote:

>On Thu, Jan 15, 2004 at 03:54:37PM -0600, Pat Gefre wrote:
>  
>
>>001-reorg.patch
>>002-reorg1.patch
>>    
>>
>
>The IS_IOADDR() stuff in the accesor funcs in pcibr_reg.c is completly
>bogus, please decide whether you want to pass a pointer to the pcibr_soft
>or bridge_t to it instead of doing second-guessing.
>
>  
>

Yes this probably looks a little odd. This was setup this way for TIO. 
The macro in the TIO code checks to see
if it is a 'soft' struct or bridge address AND what bridge type it is - 
accessing different registers depending
on TIO or not TIO (the 2 cases we have so far). We think this makes the 
register access functions pretty flexible/generic.

>Also while the pic.h changes look okay they will conflict with a patch
>I'm about to send that adds common headers for the bridge/xbow/xwidget
>register for mips and IA64.  Can you send me a version of pic.h with
>those changes and the big endian ifdefs back in so I can just incorporate
>the new version into my patch?
>
>  
>

OK - I'll look into getting this for you.

>Also are all those access you abstract away different in TIOCP?  If not
>please don't add the wrappers for them.
>  
>



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

* Re: [PATCH 2.6] Altix updates
  2004-01-20 17:50   ` Patrick Gefre
@ 2004-01-20 18:08     ` Christoph Hellwig
  2004-01-20 20:12       ` Patrick Gefre
  0 siblings, 1 reply; 11+ messages in thread
From: Christoph Hellwig @ 2004-01-20 18:08 UTC (permalink / raw)
  To: Patrick Gefre; +Cc: Christoph Hellwig, akpm, davidm, linux-kernel

On Tue, Jan 20, 2004 at 11:50:19AM -0600, Patrick Gefre wrote:
> Yes this probably looks a little odd. This was setup this way for TIO. 
> The macro in the TIO code checks to see
> if it is a 'soft' struct or bridge address AND what bridge type it is - 
> accessing different registers depending
> on TIO or not TIO (the 2 cases we have so far). We think this makes the 
> register access functions pretty flexible/generic.

Sorry, but this is completly bogus.  Just declare one accessor per
datatype.


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

* Re: [PATCH 2.6] Altix updates
  2004-01-20 18:08     ` Christoph Hellwig
@ 2004-01-20 20:12       ` Patrick Gefre
  2004-01-20 20:21         ` Christoph Hellwig
  0 siblings, 1 reply; 11+ messages in thread
From: Patrick Gefre @ 2004-01-20 20:12 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: akpm, davidm, linux-kernel

Christoph Hellwig wrote:

>On Tue, Jan 20, 2004 at 11:50:19AM -0600, Patrick Gefre wrote:
>  
>
>>Yes this probably looks a little odd. This was setup this way for TIO. 
>>The macro in the TIO code checks to see
>>if it is a 'soft' struct or bridge address AND what bridge type it is - 
>>accessing different registers depending
>>on TIO or not TIO (the 2 cases we have so far). We think this makes the 
>>register access functions pretty flexible/generic.
>>    
>>
>
>Sorry, but this is completly bogus.  Just declare one accessor per
>datatype.
>  
>

Guess I don't understand your point. Do you want us to create separate 
functions for soft-struct and bridge address
and TIO and non-TIO - 4 functions for each register access, rather than 1 ?

That seems to add a lot of extra code now and we'll need to add new 
functions as we add more ASIC interfaces - which is exactly
what we are trying to avoid. The way we have it, if we add a new ASIC we 
just need to make the lowest level functions ASIC-aware
and then we are done - no need to have blocks of if-then-else code in 
the mainline to determine which function to call.



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

* Re: [PATCH 2.6] Altix updates
  2004-01-20 20:12       ` Patrick Gefre
@ 2004-01-20 20:21         ` Christoph Hellwig
  2004-01-20 22:23           ` Patrick Gefre
  0 siblings, 1 reply; 11+ messages in thread
From: Christoph Hellwig @ 2004-01-20 20:21 UTC (permalink / raw)
  To: Patrick Gefre; +Cc: akpm, davidm, linux-kernel

On Tue, Jan 20, 2004 at 02:12:47PM -0600, Patrick Gefre wrote:
> Guess I don't understand your point. Do you want us to create separate 
> functions for soft-struct and bridge address
> and TIO and non-TIO - 4 functions for each register access, rather than 1 ?

The right fix would be to only have one, and that one would take the
bridge_t.  If you really want to have one that takes the pcibr_soft, too
make it a small wrapper.  But even that would be two and not four, where
do the other two come from?


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

* Re: [PATCH 2.6] Altix updates
  2004-01-20 20:21         ` Christoph Hellwig
@ 2004-01-20 22:23           ` Patrick Gefre
  2004-01-20 23:34             ` Christoph Hellwig
  0 siblings, 1 reply; 11+ messages in thread
From: Patrick Gefre @ 2004-01-20 22:23 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: akpm, davidm, linux-kernel

Christoph Hellwig wrote:

>On Tue, Jan 20, 2004 at 02:12:47PM -0600, Patrick Gefre wrote:
>  
>
>>Guess I don't understand your point. Do you want us to create separate 
>>functions for soft-struct and bridge address
>>and TIO and non-TIO - 4 functions for each register access, rather than 1 ?
>>    
>>
>
>The right fix would be to only have one, and that one would take the
>bridge_t.  If you really want to have one that takes the pcibr_soft, too
>make it a small wrapper.  But even that would be two and not four, where
>do the other two come from?
>  
>
I had one for bridge address/TIO, one for bridge address/nonTIO, one for 
soft address/TIO and one for soft address/nonTIO.
I thought that was what you were proposing. In any event, here's how the 
basic code looks (leaving out type defs/error checking/
etc) - the wrapper is embedded in the macro - note that we would always 
like to use the soft struct because it doesn't cost us a PIO
but in the event that the soft struct is not available the bridge 
address must be used:

#define SET_TYPE_AND_PTR(ptr, type, bridge) \
    if ( IS_IOADDR(ptr) ) { \
        if ( IS_TIO(ptr->id) ) \
            type = BT_TIO; \
        else \
            type = BT_PIC; \
        bridge_addr = ptr; \
    } else { \
        type = ptr->bs_bridge_type; \
        bridge_addr = ptr->bs_base; \
    }

void *
pcireg_xxx_get(void *ptr)
{
    SET_TYPE_AND_PTR(ptr, &type, bridge);

    switch (type ) {
        case BT_TIO:
            return bridge_addr->ti_xxx;

        case BT_PIC:
            return bridge->addr->pic_xxx;

        default:
            /* */
    }
}


Is this what you are suggesting ??

void *
pcireg_xxx_get(void *ptr)
{
    if ( IS_IOADDR(ptr) )
        return REAL_pcireg_xxx_get(ptr, IS_TIO(ptr) ? BT_TIO : BT_PIC);
    else
        return REAL_pcireg_xxx_get(ptr->bs_base, ptr->bs_bridge_type);
       
}

void *
REAL_pcireg_xxx_get(void *ptr, int type)
{
    switch (type ) {
        case BT_TIO:
            return bridge_addr->ti_xxx;

        case BT_PIC:
            return bridge->addr->pic_xxx;

        default:
            /* */
    }
}



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

* Re: [PATCH 2.6] Altix updates
  2004-01-20 22:23           ` Patrick Gefre
@ 2004-01-20 23:34             ` Christoph Hellwig
  2004-01-21  0:23               ` Patrick Gefre
  0 siblings, 1 reply; 11+ messages in thread
From: Christoph Hellwig @ 2004-01-20 23:34 UTC (permalink / raw)
  To: Patrick Gefre; +Cc: akpm, davidm, linux-kernel

On Tue, Jan 20, 2004 at 04:23:50PM -0600, Patrick Gefre wrote:
> I had one for bridge address/TIO, one for bridge address/nonTIO, one for 
> soft address/TIO and one for soft address/nonTIO.
> I thought that was what you were proposing. In any event, here's how the 
> basic code looks (leaving out type defs/error checking/
> etc) - the wrapper is embedded in the macro - note that we would always 
> like to use the soft struct because it doesn't cost us a PIO
> but in the event that the soft struct is not available the bridge 
> address must be used:

(horrible piece of sh^H^H^code snipped)

Eeek!

So taking your pio cycle stuff into account, what about:

void *
__pcireg_xxx_get(bridge_t *bridge, int type)
{
     switch (type ) {
        case BT_TIO:
            return bridge_addr->ti_xxx;

        case BT_PIC:
            return bridge->addr->pic_xxx;

        default:
            /* */
    }
}

and then have wrappers for both the plain bridge_t and the pcibr_soft.
In fact I wonder why you want the one taking bridge_t at all, there is
absolutely no reason why you should be able to get a bridge_t without
getting at the pcibr_soft easily.
> 
> void *
> pcireg_xxx_get(void *ptr)
> {
>     if ( IS_IOADDR(ptr) )
>         return REAL_pcireg_xxx_get(ptr, IS_TIO(ptr) ? BT_TIO : BT_PIC);
>     else
>         return REAL_pcireg_xxx_get(ptr->bs_base, ptr->bs_bridge_type);
>        
> }

No, this is borked again.  The IS_IOADDR tests must go away.


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

* Re: [PATCH 2.6] Altix updates
  2004-01-20 23:34             ` Christoph Hellwig
@ 2004-01-21  0:23               ` Patrick Gefre
  2004-01-21  0:26                 ` Christoph Hellwig
  0 siblings, 1 reply; 11+ messages in thread
From: Patrick Gefre @ 2004-01-21  0:23 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: akpm, davidm, linux-kernel

Christoph Hellwig wrote:

>On Tue, Jan 20, 2004 at 04:23:50PM -0600, Patrick Gefre wrote:
>  
>
>>I had one for bridge address/TIO, one for bridge address/nonTIO, one for 
>>soft address/TIO and one for soft address/nonTIO.
>>I thought that was what you were proposing. In any event, here's how the 
>>basic code looks (leaving out type defs/error checking/
>>etc) - the wrapper is embedded in the macro - note that we would always 
>>like to use the soft struct because it doesn't cost us a PIO
>>but in the event that the soft struct is not available the bridge 
>>address must be used:
>>    
>>
>
>(horrible piece of sh^H^H^code snipped)
>
>Eeek!
>
>So taking your pio cycle stuff into account, what about:
>
>void *
>__pcireg_xxx_get(bridge_t *bridge, int type)
>{
>     switch (type ) {
>        case BT_TIO:
>            return bridge_addr->ti_xxx;
>
>        case BT_PIC:
>            return bridge->addr->pic_xxx;
>
>        default:
>            /* */
>    }
>}
>
>and then have wrappers for both the plain bridge_t and the pcibr_soft.
>In fact I wonder why you want the one taking bridge_t at all, there is
>absolutely no reason why you should be able to get a bridge_t without
>getting at the pcibr_soft easily.
>  
>
>>void *
>>pcireg_xxx_get(void *ptr)
>>{
>>    if ( IS_IOADDR(ptr) )
>>        return REAL_pcireg_xxx_get(ptr, IS_TIO(ptr) ? BT_TIO : BT_PIC);
>>    else
>>        return REAL_pcireg_xxx_get(ptr->bs_base, ptr->bs_bridge_type);
>>       
>>}
>>    
>>
>
>No, this is borked again.  The IS_IOADDR tests must go away.
>
>  
>

So something like this will work for you ???

void *
pcireg_xxx_soft_get(ptr)
{
        return __pcireg_xxx_get(ptr->bs_base, ptr->bs_bridge_type);
}

void *
pcireg_xxx_get(ptr)
{
        return __pcireg_xxx_get(ptr, IS_TIO(ptr) ? BT_TIO : BT_PIC);
}

static void *
__pcireg_xxx_get(bridge_t *bridge, int type)
{
     switch (type ) {
        case BT_TIO:
            return bridge_addr->ti_xxx;

        case BT_PIC:
            return bridge->addr->pic_xxx;

        default:
            /* */
    }
}




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

* Re: [PATCH 2.6] Altix updates
  2004-01-21  0:23               ` Patrick Gefre
@ 2004-01-21  0:26                 ` Christoph Hellwig
  0 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2004-01-21  0:26 UTC (permalink / raw)
  To: Patrick Gefre; +Cc: akpm, davidm, linux-kernel

On Tue, Jan 20, 2004 at 06:23:24PM -0600, Patrick Gefre wrote:
> So something like this will work for you ???

Yes.  Although I'd really like to see a rationale why you need the version
operating on the I/O addresses at all.  The only thing I could up with is
that someone is too lazy to update a bunch of function prototypes. 


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

end of thread, other threads:[~2004-01-21  0:26 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-15 21:54 [PATCH 2.6] Altix updates Pat Gefre
2004-01-16  2:34 ` Andrew Morton
2004-01-16 14:41 ` Christoph Hellwig
2004-01-20 17:50   ` Patrick Gefre
2004-01-20 18:08     ` Christoph Hellwig
2004-01-20 20:12       ` Patrick Gefre
2004-01-20 20:21         ` Christoph Hellwig
2004-01-20 22:23           ` Patrick Gefre
2004-01-20 23:34             ` Christoph Hellwig
2004-01-21  0:23               ` Patrick Gefre
2004-01-21  0:26                 ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox