kill two dead headers
PATCH 1/1 kill two dead headers
Kill two headers never references in the current tree.
mmtimer_private.h renamed from include/asm-ia64/sn/mmtimer_private.h +0 -42
@@ -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 */
uart16550.h renamed from include/asm-ia64/sn/uart16550.h +0 -227
227 lines not on this page · raw message
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
[email protected]
WORK: 651-683-3131
HOME: 651-407-0134
--
Quoted 4 lines · Alan Mayer
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
On Tue, 7 Oct 2003, Sam Ravnborg wrote:
Yup. That was one of the things we're working to correct.
--ajm
Quoted 11 lines
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.
Quoted 2 lines
Sam
Somebody just stopped callin' you "Angel."
--
Alan J. Mayer
SGI
[email protected]
WORK: 651-683-3131
HOME: 651-407-0134
--
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 6 lines · Christoph Hellwig
Quoted 2 lines
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.
Quoted 9 lines
Quoted 6 lines
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.
Quoted 10 lines
Quoted 4 lines
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
[email protected]
WORK: 651-683-3131
HOME: 651-407-0134
--
Quoted 5 lines · Alan Mayer
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.
Quoted 8 lines · Alan Mayer
Quoted 4 lines
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
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
Quoted 9 lines · David Mosberger
- 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.