* [PATCH] kill two dead headers
@ 2003-09-25 18:08 Christoph Hellwig
2003-10-07 16:44 ` Alan Mayer
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: Christoph Hellwig @ 2003-09-25 18:08 UTC (permalink / raw)
To: linux-ia64
Kill two headers never references in the current tree.
--- 1.2/include/asm-ia64/sn/mmtimer_private.h Fri May 16 13:18:17 2003
+++ edited/mmtimer_private.h Thu Sep 25 19:58:56 2003
@@ -1,42 +0,0 @@
-/*
- * Intel Multimedia Timer device interface
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (c) 2001-2003 Silicon Graphics, Inc. All rights reserved.
- *
- * Helper file for the SN implementation of mmtimers
- *
- * 11/01/01 - jbarnes - initial revision
- */
-
-#ifndef _SN_MMTIMER_PRIVATE_H
-
-#define RTC_BITS 55 /* 55 bits for this implementation */
-#define NUM_COMPARATORS 2 /* two comparison registers in SN1 */
-
-/*
- * Check for an interrupt and clear the pending bit if
- * one is waiting.
- */
-#define MMTIMER_INT_PENDING(x) (x ? *(RTC_INT_PENDING_B_ADDR) : *(RTC_INT_PENDING_A_ADDR))
-
-/*
- * Set interrupts on RTC 'x' to 'v' (true or false)
- */
-#define MMTIMER_SET_INT(x,v) (x ? (*(RTC_INT_ENABLED_B_ADDR) = (unsigned long)(v)) : (*(RTC_INT_ENABLED_A_ADDR) = (unsigned long)(v)))
-
-#define MMTIMER_ENABLE_INT(x) MMTIMER_SET_INT(x, 1)
-#define MMTIMER_DISABLE_INT(x) MMTIMER_SET_INT(x, 0)
-
-typedef struct mmtimer {
- spinlock_t timer_lock;
- unsigned long periodic;
- int signo;
- volatile unsigned long *compare;
- struct task_struct *process;
-} mmtimer_t;
-
-#endif /* _SN_LINUX_MMTIMER_PRIVATE_H */
--- 1.4/include/asm-ia64/sn/uart16550.h Fri May 16 13:18:17 2003
+++ edited/uart16550.h Thu Sep 25 19:58:57 2003
@@ -1,227 +0,0 @@
-/*
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1992-1997,2000-2003 Silicon Graphics, Inc. All rights reserved.
- */
-
-#ifndef _ASM_IA64_SN_UART16550_H
-#define _ASM_IA64_SN_UART16550_H
-
-
-/*
- * Definitions for 16550 chip
- */
-
- /* defined as offsets from the data register */
-#define REG_DAT 0 /* receive/transmit data */
-#define REG_ICR 1 /* interrupt control register */
-#define REG_ISR 2 /* interrupt status register */
-#define REG_FCR 2 /* fifo control register */
-#define REG_LCR 3 /* line control register */
-#define REG_MCR 4 /* modem control register */
-#define REG_LSR 5 /* line status register */
-#define REG_MSR 6 /* modem status register */
-#define REG_SCR 7 /* Scratch register */
-#define REG_DLL 0 /* divisor latch (lsb) */
-#define REG_DLH 1 /* divisor latch (msb) */
-#define REG_EFR 2 /* 16650 enhanced feature register */
-
-/*
- * 16450/16550 Registers Structure.
- */
-
-/* Line Control Register */
-#define LCR_WLS0 0x01 /*word length select bit 0 */
-#define LCR_WLS1 0x02 /*word length select bit 2 */
-#define LCR_STB 0x04 /* number of stop bits */
-#define LCR_PEN 0x08 /* parity enable */
-#define LCR_EPS 0x10 /* even parity select */
-#define LCR_SETBREAK 0x40 /* break key */
-#define LCR_DLAB 0x80 /* divisor latch access bit */
-#define LCR_RXLEN 0x03 /* # of data bits per received/xmitted char */
-#define LCR_STOP1 0x00
-#define LCR_STOP2 0x04
-#define LCR_PAREN 0x08
-#define LCR_PAREVN 0x10
-#define LCR_PARMARK 0x20
-#define LCR_SNDBRK 0x40
-#define LCR_DLAB 0x80
-
-
-#define LCR_BITS5 0x00 /* 5 bits per char */
-#define LCR_BITS6 0x01 /* 6 bits per char */
-#define LCR_BITS7 0x02 /* 7 bits per char */
-#define LCR_BITS8 0x03 /* 8 bits per char */
-
-#define LCR_MASK_BITS_CHAR 0x03
-#define LCR_MASK_STOP_BITS 0x04
-#define LCR_MASK_PARITY_BITS 0x18
-
-
-/* Line Status Register */
-#define LSR_RCA 0x01 /* data ready */
-#define LSR_OVRRUN 0x02 /* overrun error */
-#define LSR_PARERR 0x04 /* parity error */
-#define LSR_FRMERR 0x08 /* framing error */
-#define LSR_BRKDET 0x10 /* a break has arrived */
-#define LSR_XHRE 0x20 /* tx hold reg is now empty */
-#define LSR_XSRE 0x40 /* tx shift reg is now empty */
-#define LSR_RFBE 0x80 /* rx FIFO Buffer error */
-
-/* Interrupt Status Regisger */
-#define ISR_MSTATUS 0x00
-#define ISR_TxRDY 0x02
-#define ISR_RxRDY 0x04
-#define ISR_ERROR_INTR 0x08
-#define ISR_FFTMOUT 0x0c /* FIFO Timeout */
-#define ISR_RSTATUS 0x06 /* Receiver Line status */
-
-/* Interrupt Enable Register */
-#define ICR_RIEN 0x01 /* Received Data Ready */
-#define ICR_TIEN 0x02 /* Tx Hold Register Empty */
-#define ICR_SIEN 0x04 /* Receiver Line Status */
-#define ICR_MIEN 0x08 /* Modem Status */
-
-/* Modem Control Register */
-#define MCR_DTR 0x01 /* Data Terminal Ready */
-#define MCR_RTS 0x02 /* Request To Send */
-#define MCR_OUT1 0x04 /* Aux output - not used */
-#define MCR_OUT2 0x08 /* turns intr to 386 on/off */
-#define MCR_LOOP 0x10 /* loopback for diagnostics */
-#define MCR_AFE 0x20 /* Auto flow control enable */
-
-/* Modem Status Register */
-#define MSR_DCTS 0x01 /* Delta Clear To Send */
-#define MSR_DDSR 0x02 /* Delta Data Set Ready */
-#define MSR_DRI 0x04 /* Trail Edge Ring Indicator */
-#define MSR_DDCD 0x08 /* Delta Data Carrier Detect */
-#define MSR_CTS 0x10 /* Clear To Send */
-#define MSR_DSR 0x20 /* Data Set Ready */
-#define MSR_RI 0x40 /* Ring Indicator */
-#define MSR_DCD 0x80 /* Data Carrier Detect */
-
-#define DELTAS(x) ((x)&(MSR_DCTS|MSR_DDSR|MSR_DRI|MSR_DDCD))
-#define STATES(x) ((x)(MSR_CTS|MSR_DSR|MSR_RI|MSR_DCD))
-
-
-#define FCR_FIFOEN 0x01 /* enable receive/transmit fifo */
-#define FCR_RxFIFO 0x02 /* enable receive fifo */
-#define FCR_TxFIFO 0x04 /* enable transmit fifo */
-#define FCR_MODE1 0x08 /* change to mode 1 */
-#define RxLVL0 0x00 /* Rx fifo level at 1 */
-#define RxLVL1 0x40 /* Rx fifo level at 4 */
-#define RxLVL2 0x80 /* Rx fifo level at 8 */
-#define RxLVL3 0xc0 /* Rx fifo level at 14 */
-
-#define FIFOEN (FCR_FIFOEN | FCR_RxFIFO | FCR_TxFIFO | RxLVL3 | FCR_MODE1)
-
-#define FCT_TxMASK 0x30 /* mask for Tx trigger */
-#define FCT_RxMASK 0xc0 /* mask for Rx trigger */
-
-/* enhanced festures register */
-#define EFR_SFLOW 0x0f /* various S/w Flow Controls */
-#define EFR_EIC 0x10 /* Enhanced Interrupt Control bit */
-#define EFR_SCD 0x20 /* Special Character Detect */
-#define EFR_RTS 0x40 /* RTS flow control */
-#define EFR_CTS 0x80 /* CTS flow control */
-
-/* Rx Tx software flow controls in 16650 enhanced mode */
-#define SFLOW_Tx0 0x00 /* no Xmit flow control */
-#define SFLOW_Tx1 0x08 /* Transmit Xon1, Xoff1 */
-#define SFLOW_Tx2 0x04 /* Transmit Xon2, Xoff2 */
-#define SFLOW_Tx3 0x0c /* Transmit Xon1,Xon2, Xoff1,Xoff2 */
-#define SFLOW_Rx0 0x00 /* no Rcv flow control */
-#define SFLOW_Rx1 0x02 /* Receiver compares Xon1, Xoff1 */
-#define SFLOW_Rx2 0x01 /* Receiver compares Xon2, Xoff2 */
-
-#define ASSERT_DTR(x) (x |= MCR_DTR)
-#define ASSERT_RTS(x) (x |= MCR_RTS)
-#define DU_RTS_ASSERTED(x) (((x) & MCR_RTS) != 0)
-#define DU_RTS_ASSERT(x) ((x) |= MCR_RTS)
-#define DU_RTS_DEASSERT(x) ((x) &= ~MCR_RTS)
-
-
-/*
- * ioctl(fd, I_STR, arg)
- * use the SIOC_RS422 and SIOC_EXTCLK combination to support MIDI
- */
-#define SIOC ('z' << 8) /* z for z85130 */
-#define SIOC_EXTCLK (SIOC | 1) /* select/de-select external clock */
-#define SIOC_RS422 (SIOC | 2) /* select/de-select RS422 protocol */
-#define SIOC_ITIMER (SIOC | 3) /* upstream timer adjustment */
-#define SIOC_LOOPBACK (SIOC | 4) /* diagnostic loopback test mode */
-
-
-/* channel control register */
-#define DMA_INT_MASK 0xe0 /* ring intr mask */
-#define DMA_INT_TH25 0x20 /* 25% threshold */
-#define DMA_INT_TH50 0x40 /* 50% threshold */
-#define DMA_INT_TH75 0x60 /* 75% threshold */
-#define DMA_INT_EMPTY 0x80 /* ring buffer empty */
-#define DMA_INT_NEMPTY 0xa0 /* ring buffer not empty */
-#define DMA_INT_FULL 0xc0 /* ring buffer full */
-#define DMA_INT_NFULL 0xe0 /* ring buffer not full */
-
-#define DMA_CHANNEL_RESET 0x400 /* reset dma channel */
-#define DMA_ENABLE 0x200 /* enable DMA */
-
-/* peripheral controller intr status bits applicable to serial ports */
-#define ISA_SERIAL0_MASK 0x03f00000 /* mask for port #1 intrs */
-#define ISA_SERIAL0_DIR 0x00100000 /* device intr request */
-#define ISA_SERIAL0_Tx_THIR 0x00200000 /* Transmit DMA threshold */
-#define ISA_SERIAL0_Tx_PREQ 0x00400000 /* Transmit DMA pair req */
-#define ISA_SERIAL0_Tx_MEMERR 0x00800000 /* Transmit DMA memory err */
-#define ISA_SERIAL0_Rx_THIR 0x01000000 /* Receive DMA threshold */
-#define ISA_SERIAL0_Rx_OVERRUN 0x02000000 /* Receive DMA over-run */
-
-#define ISA_SERIAL1_MASK 0xfc000000 /* mask for port #1 intrs */
-#define ISA_SERIAL1_DIR 0x04000000 /* device intr request */
-#define ISA_SERIAL1_Tx_THIR 0x08000000 /* Transmit DMA threshold */
-#define ISA_SERIAL1_Tx_PREQ 0x10000000 /* Transmit DMA pair req */
-#define ISA_SERIAL1_Tx_MEMERR 0x20000000 /* Transmit DMA memory err */
-#define ISA_SERIAL1_Rx_THIR 0x40000000 /* Receive DMA threshold */
-#define ISA_SERIAL1_Rx_OVERRUN 0x80000000 /* Receive DMA over-run */
-
-#define MAX_RING_BLOCKS 128 /* 4096/32 */
-#define MAX_RING_SIZE 4096
-
-/* DMA Input Control Byte */
-#define DMA_IC_OVRRUN 0x01 /* overrun error */
-#define DMA_IC_PARERR 0x02 /* parity error */
-#define DMA_IC_FRMERR 0x04 /* framing error */
-#define DMA_IC_BRKDET 0x08 /* a break has arrived */
-#define DMA_IC_VALID 0x80 /* pair is valid */
-
-/* DMA Output Control Byte */
-#define DMA_OC_TxINTR 0x20 /* set Tx intr after processing byte */
-#define DMA_OC_INVALID 0x00 /* invalid pair */
-#define DMA_OC_WTHR 0x40 /* Write byte to THR */
-#define DMA_OC_WMCR 0x80 /* Write byte to MCR */
-#define DMA_OC_DELAY 0xc0 /* time delay before next xmit */
-
-/* ring id's */
-#define RID_SERIAL0_TX 0x4 /* serial port 0, transmit ring buffer */
-#define RID_SERIAL0_RX 0x5 /* serial port 0, receive ring buffer */
-#define RID_SERIAL1_TX 0x6 /* serial port 1, transmit ring buffer */
-#define RID_SERIAL1_RX 0x7 /* serial port 1, receive ring buffer */
-
-#define CLOCK_XIN 22
-#define PRESCALER_DIVISOR 3
-#define CLOCK_ACE 7333333
-
-/*
- * increment the ring offset. One way to do this would be to add b'100000.
- * this would let the offset value roll over automatically when it reaches
- * its maximum value (127). However when we use the offset, we must use
- * the appropriate bits only by masking with 0xfe0.
- * The other option is to shift the offset right by 5 bits and look at its
- * value. Then increment if required and shift back
- * note: 127 * 2^5 = 4064
- */
-#define INC_RING_POINTER(x) \
- ( ((x & 0xffe0) < 4064) ? (x += 32) : 0 )
-
-#endif /* _ASM_IA64_SN_UART16550_H */
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
@ 2003-10-07 16:44 ` Alan Mayer
2003-10-07 20:46 ` Sam Ravnborg
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Alan Mayer @ 2003-10-07 16:44 UTC (permalink / raw)
To: linux-ia64
This is in response to a series of patches from Christoph Hellwig
against the SGI IO infrastructure. These patches fall into three
categories, but first let me say this: There is nothing wrong with
what Christoph is trying to do. The IO infrastructure needs work.
It is also complicated, too complicated. We at SGI are addressing
the issues that Christoph raises and more. We also have the resources,
both people and machines, to address these issues effectively. Our
failure has been the slowness with which we have pushed our code into
2.6. This is also being addressed. Now the categories:
1. It's already been done. Many of the patches that Christoph submitted
have been taken care of here at SGI, but the code hasn't been pushed
out to 2.6. Some of Christoph's patches in this category are incomplete.
Some of the code he deleted performs a necessary function and his
patches result in panic's. Were the patches tested on HW? What
configurations? These patches include:
[PATCH] kill two dead headers.
[PATCH] make sn2 devfs-clean.
[PATCH] kill sn_ksyms.c.
[PATCH] kill sn2 inventory stubs.
[PATCH] kill dead code from ml_iograph.c.
[PATCH] kill .hcl entry in hwgfs.
[PATCH] remove CONFIG_PCI ifdefs in SN2 code.
[PATCH] more dead headers.
[PATCH] kill arc leftovers.
[PATCH] kill machvec_sn1.h.
[PATCH] kill more inventory code.
[PATCH] fix two compiler warnings in SN2 code.
2. It should be done, but it's not nearly as simple as it appears. We
have someone assigned to work on it, including issues regarding unobvious
dependence on or by other parts of the code, and requirements of planned,
but unreleased, new hardware. These things require extensive testing with
various HW configs.
[PATCH] kill snia_pciio_*
[PATCH] simplify and speedup SN2 dma mapping.
[PATCH] sn_ML_intr.c is a freakin mess.
[PATCH] simplify SN2 interrupt allocation.
[PATCH] fix the sn_pci_fixup mess.
[PATCH] update arch/ia64/sn/kernel/sn2/Makefile.
[PATCH] avoid a layer of indirection in SN2 pci config space access.
[PATCH] sanitize SN2 pci resource setup.
[PATCH] kill pciio_provider*.
[PATCH] fix intr_heuristic().
3. Don't care or it's fine to put in.
[PATCH] kill kdba_io.c
[PATCH] kill sn_ksyms.c
It would simplify our lives enormously if none of these patches were applied, with the possible
exception of the last two. They're pretty much stomping all over work already in progress or
introducing bugs that we don't really have the time or resources to track down and fix.
--ajm
Lately it occurs to me,
What a long, strange trip it's been.
--
Alan J. Mayer
SGI
ajm@sgi.com
WORK: 651-683-3131
HOME: 651-407-0134
--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
2003-10-07 16:44 ` Alan Mayer
@ 2003-10-07 20:46 ` Sam Ravnborg
2003-10-07 21:20 ` Alan Mayer
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Sam Ravnborg @ 2003-10-07 20:46 UTC (permalink / raw)
To: linux-ia64
On Tue, Oct 07, 2003 at 11:44:49AM -0500, Alan Mayer wrote:
>
> It would simplify our lives enormously if none of these patches were applied, with the possible
> exception of the last two. They're pretty much stomping all over work already in progress or
> introducing bugs that we don't really have the time or resources to track down and fix.
Reading the above it occurs to me you are aiming for "flag-day patches".
Try to keep in sync with main-line instead is a *much* better approach.
If you are having troubles getting your patches applied, maybe it's
due to the size anyway.
See how Martin does it for S390 for example. 5-20 paches each 3 weeks in
average. And he gets good feedback - also from others than hch.
Developing everything in vacuum is the wrong approach, and does not
give you any feedback from the community - or at least you get it
only indirect with patches that hch creates.
Sam
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
2003-10-07 16:44 ` Alan Mayer
2003-10-07 20:46 ` Sam Ravnborg
@ 2003-10-07 21:20 ` Alan Mayer
2003-10-08 13:15 ` Christoph Hellwig
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Alan Mayer @ 2003-10-07 21:20 UTC (permalink / raw)
To: linux-ia64
On Tue, 7 Oct 2003, Sam Ravnborg wrote:
Yup. That was one of the things we're working to correct.
--ajm
>
> Reading the above it occurs to me you are aiming for "flag-day patches".
> Try to keep in sync with main-line instead is a *much* better approach.
> If you are having troubles getting your patches applied, maybe it's
> due to the size anyway.
> See how Martin does it for S390 for example. 5-20 paches each 3 weeks in
> average. And he gets good feedback - also from others than hch.
> Developing everything in vacuum is the wrong approach, and does not
> give you any feedback from the community - or at least you get it
> only indirect with patches that hch creates.
>
> Sam
>
Somebody just stopped callin' you "Angel."
--
Alan J. Mayer
SGI
ajm@sgi.com
WORK: 651-683-3131
HOME: 651-407-0134
--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
` (2 preceding siblings ...)
2003-10-07 21:20 ` Alan Mayer
@ 2003-10-08 13:15 ` Christoph Hellwig
2003-10-08 16:40 ` Alan Mayer
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Christoph Hellwig @ 2003-10-08 13:15 UTC (permalink / raw)
To: linux-ia64
> It is also complicated, too complicated. We at SGI are addressing
> the issues that Christoph raises and more.
You are not. You're ignoring suggestions and calling me names
after patches. Jesse and Jes are doing nice work OTOH but you
are in the way of fixing the total mess up.
> 1. It's already been done. Many of the patches that Christoph submitted
> have been taken care of here at SGI, but the code hasn't been pushed
> out to 2.6. Some of Christoph's patches in this category are incomplete.
> Some of the code he deleted performs a necessary function and his
> patches result in panic's.
That's why they are sent to a public list. If one of the patches is
wrong please follow up to the patch and explain why.
> It would simplify our lives enormously if none of these patches were applied, with the possible
> exception of the last two. They're pretty much stomping all over work already in progress or
> introducing bugs that we don't really have the time or resources to track down and fix.
So submit your patches. Jesse ACKed most of these and said he's waiting
for your group for more feedback. This didn't happen for more than a
month so I've send them to a public list. Seems like this is the only
way to get more feedback from you than insults.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
` (3 preceding siblings ...)
2003-10-08 13:15 ` Christoph Hellwig
@ 2003-10-08 16:40 ` Alan Mayer
2003-10-08 16:46 ` Christoph Hellwig
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Alan Mayer @ 2003-10-08 16:40 UTC (permalink / raw)
To: linux-ia64
On Wed, 8 Oct 2003, Christoph Hellwig wrote:
> > It is also complicated, too complicated. We at SGI are addressing
> > the issues that Christoph raises and more.
>
> You are not. You're ignoring suggestions and calling me names
> after patches. Jesse and Jes are doing nice work OTOH but you
> are in the way of fixing the total mess up.
Well, yes, we are. The big issue seems to be the sluggish way we push
our code out to kernel.org, particularly the 2.6 tree. We are addressing
that problem. Aggressively. Emphatically. It's a huge problem and
one that we (SGI) have to fix quickly.
>
> > 1. It's already been done. Many of the patches that Christoph submitted
> > have been taken care of here at SGI, but the code hasn't been pushed
> > out to 2.6. Some of Christoph's patches in this category are incomplete.
> > Some of the code he deleted performs a necessary function and his
> > patches result in panic's.
>
> That's why they are sent to a public list. If one of the patches is
> wrong please follow up to the patch and explain why.
Whether or not there are problems with one or more of the patches isn't really
the issue. Our issue is that the patches are addressing things that have been
or are going to be addressed by the maintainers of the SGI IO infrastructure.
We are trying to avoid a situation where patches get in the way of what we're
trying to accomplish.
>
> > It would simplify our lives enormously if none of these patches were applied, with the possible
> > exception of the last two. They're pretty much stomping all over work already in progress or
> > introducing bugs that we don't really have the time or resources to track down and fix.
>
> So submit your patches. Jesse ACKed most of these and said he's waiting
> for your group for more feedback. This didn't happen for more than a
> month so I've send them to a public list. Seems like this is the only
> way to get more feedback from you than insults.
>
I received one of your patches from Jesse about a week ago. I responded to
him. That has been the extent of it. I can't address this communication
failure beyond that.
We have been conducting a series of discussions on this subject internally.
The suggestions we have gotten from Jes, et al, have been good ones and
have been incorporated into our plans. Your name has rarely come up. If
you have been expecting feedback from us (the IO infrastructure group), no
one mentioned it to us.
--ajm
If I swallow anything evil,
Put your finger down my throat.
--
Alan J. Mayer
SGI
ajm@sgi.com
WORK: 651-683-3131
HOME: 651-407-0134
--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
` (4 preceding siblings ...)
2003-10-08 16:40 ` Alan Mayer
@ 2003-10-08 16:46 ` Christoph Hellwig
2003-10-08 17:30 ` Jesse Barnes
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Christoph Hellwig @ 2003-10-08 16:46 UTC (permalink / raw)
To: linux-ia64
On Wed, Oct 08, 2003 at 11:40:05AM -0500, Alan Mayer wrote:
> Whether or not there are problems with one or more of the patches isn't really
> the issue. Our issue is that the patches are addressing things that have been
> or are going to be addressed by the maintainers of the SGI IO infrastructure.
> We are trying to avoid a situation where patches get in the way of what we're
> trying to accomplish.
Oh yes. Please comment on the individual patches, explain why you don't
like them / what you don't like. Jesse liked all of them so far and
your say either you already have fixes in the magic secret or will do
fixes once time permits. But my fixes are there and no now, in the
public and partially applied. Please comment on the outstanding one on
the list _NOW_ or shut up forever. And just FYI: according to the
MAINTAINERS file Jesse is maintainer for SN2, so his word counts, not
yours.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
` (5 preceding siblings ...)
2003-10-08 16:46 ` Christoph Hellwig
@ 2003-10-08 17:30 ` Jesse Barnes
2003-10-09 20:36 ` David Mosberger
2003-10-10 9:28 ` Christoph Hellwig
8 siblings, 0 replies; 10+ messages in thread
From: Jesse Barnes @ 2003-10-08 17:30 UTC (permalink / raw)
To: linux-ia64
On Wed, Oct 08, 2003 at 11:40:05AM -0500, Alan Mayer wrote:
> > So submit your patches. Jesse ACKed most of these and said he's waiting
> > for your group for more feedback. This didn't happen for more than a
> > month so I've send them to a public list. Seems like this is the only
> > way to get more feedback from you than insults.
>
> I received one of your patches from Jesse about a week ago. I responded to
> him. That has been the extent of it. I can't address this communication
> failure beyond that.
Sorry, this is partly my fault. I gave Colin a heads up about all these
changes, but he went on vacation before he had a chance to comment.
Colin should probably be listed as the person responsible for
arch/ia64/sn/io since he's been involved with it for the longest.
Thanks,
Jesse
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
` (6 preceding siblings ...)
2003-10-08 17:30 ` Jesse Barnes
@ 2003-10-09 20:36 ` David Mosberger
2003-10-10 9:28 ` Christoph Hellwig
8 siblings, 0 replies; 10+ messages in thread
From: David Mosberger @ 2003-10-09 20:36 UTC (permalink / raw)
To: linux-ia64
OK, I was under the impression that Christoph was working with SGI's
approval. I don't want to get into the middle of an SGI-internal
dispute so I'm proposing to do the following:
- The patches that got accepted already will stay there. In my
opinion, they improve the state of the SN directories and
personally I'm glad to see someone finally started to clean them
up. I'm sorry if this causes some conflicts with an SGI-internal
tree, but we have only the public tree to go by. Hopefully, it's
reasonably straightforward to merge Christoph's patches into your
internal tree.
- For the future, I'll accept patches for the SN tree only from Jesse
Barnes (of course, you can delegate internally as you wish, but I
prefer to have a single contact for the SN subdirectories and Jesse
has proven responsive and responsible so far). Of course, should
there be complaints that contributed patches are not handled in a
timely fashion (as Christoph alleged), then we may have to revise
this decision.
Does this work for everyone?
--david
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] kill two dead headers
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
` (7 preceding siblings ...)
2003-10-09 20:36 ` David Mosberger
@ 2003-10-10 9:28 ` Christoph Hellwig
8 siblings, 0 replies; 10+ messages in thread
From: Christoph Hellwig @ 2003-10-10 9:28 UTC (permalink / raw)
To: linux-ia64
On Thu, Oct 09, 2003 at 01:36:51PM -0700, David Mosberger wrote:
> - For the future, I'll accept patches for the SN tree only from Jesse
> Barnes (of course, you can delegate internally as you wish, but I
> prefer to have a single contact for the SN subdirectories and Jesse
> has proven responsive and responsible so far). Of course, should
> there be complaints that contributed patches are not handled in a
> timely fashion (as Christoph alleged), then we may have to revise
> this decision.
>
> Does this work for everyone?
fine with me. The patches went to Jesse & you anyway, mostly so that
you could apply them when Jesse ACKs them.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-10-10 9:28 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-25 18:08 [PATCH] kill two dead headers Christoph Hellwig
2003-10-07 16:44 ` Alan Mayer
2003-10-07 20:46 ` Sam Ravnborg
2003-10-07 21:20 ` Alan Mayer
2003-10-08 13:15 ` Christoph Hellwig
2003-10-08 16:40 ` Alan Mayer
2003-10-08 16:46 ` Christoph Hellwig
2003-10-08 17:30 ` Jesse Barnes
2003-10-09 20:36 ` David Mosberger
2003-10-10 9:28 ` Christoph Hellwig
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.