Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007 21:37:37 +0100 Ingo Molnar wrote: > ok, then you conceded it by not replying to it? good ;-) No, I don't intend to carry on this discussion, but I appreciate the smiley. --- ~Randy
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007 21:16:39 +0100 Ingo Molnar wrote: > countered by the underlined sentences above, just in case you missed it. I didn't miss your claim. --- ~Randy
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > * Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > (and this is in no way directed at the networking folks - it holds > > > for all of us. I have one main complaint about networking: the > > > separate netdev list is a bad idea - networking regressions should > > > be discussed and fixed on lkml, like most other subsystems are. Any > > > artificial split of the lk discussion space is bad.) > > > > but here I disagree. LKML is already too busy and noisy. Major > > subsystems need their own discussion areas. > > That's a stupid argument. We lose much more by forced isolation of > discussion than what we win by having less traffic! It's _MUCH_ easier > to narrow down information (by filter by threads, by topics, by people, > etc.) than it is to gobble information together from various fractured > sources. We learned it _again and again_ that isolation of kernel > discussions causes bad things. > > In fact this thread is the very example: David points out that on netdev > some of those bugs were already discussed and resolved. Had it been all > on lkml we'd all be aware of it. or had been on netdev. > this is a single kernel project that is released together as one > codebase, so a central place of discussion is obvious and common-sense. Central doesn't have to mean one-and-only-one-list-for-everything. > so please stop this "too busy and too noisy" nonsense already. It was > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > grew from a 1 million lines codebase to an 8 million lines codebase, so > what? Deal with it and be intelligent about filtering your information > influx instead of imposing a hard pre-filtering criteria that restricts > intelligent processing of information. So you have a preferred method of handling email. Please don't force it on the rest of us. I'll plan to use lkml-list-only when you have convinced DaveM to drop all of the other mailing lists at vger.kernel.org. Yeah, sure. --- ~Randy
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 09:33:21 -0600 James Bottomley wrote: > On Tue, 2007-11-13 at 03:15 -0800, Andrew Morton wrote: > > > > > SCSI== > > > > > > qla2xxx: driver initialization does not complete when booting with > > > Port connected > > > http://bugzilla.kernel.org/show_bug.cgi?id=9267 > > > Kernel: 2.6.23.1 > > > > No response from developers > > Urm, well, if no-one ever tells the SCSI list it's unrealistic to expect > anyone to be working on it. As far as I can tell, email was sent to > Andrew Vasquez only on 31 October. However, the fault looks to be > generic, so he probably just dropped it. It seems that new SCSI bugs need to be sent to [EMAIL PROTECTED] Martin, can you arrange that to happen automatically instead of Andrew having to do it manually? --- ~Randy
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 14:40:29 +0100 Ingo Molnar wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Do you believe that our response to bug reports is adequate? > > > > > > Do you feel that making us feel and look like shit helps? > > > > That doesn't answer my question. > > > > See, first we need to work out whether we have a problem. If we do > > this, then we can then have a think about what to do about it. > > > > I tried to convince the 2006 KS attendees that we have a problem and I > > resoundingly failed. People seemed to think that we're doing OK. We were a minority. > > But it appears that data such as this contradicts that belief. > > > > This is not a minor matter. If the kernel _is_ slowly deteriorating > > then this won't become readily apparent until it has been happening > > for a number of years. By that stage there will be so much work to do > > to get us back to an acceptable level that it will take a huge effort. > > And it will take a long time after that for the kerel to get its > > reputation back. > > > > So it is important that we catch deterioration *early* if it is > > happening. > [agree with most of Ingo's moaning] > (and this is in no way directed at the networking folks - it holds for > all of us. I have one main complaint about networking: the separate > netdev list is a bad idea - networking regressions should be discussed > and fixed on lkml, like most other subsystems are. Any artificial split > of the lk discussion space is bad.) but here I disagree. LKML is already too busy and noisy. Major subsystems need their own discussion areas. --- ~Randy
[PATCH] input: move gameports out of SERIO menu
From: Randy Dunlap <[EMAIL PROTECTED]> Move the gameport support menu out of the SERIO menu and put it between touchscreens and misc. devices in the main input layer menu. Change it to use menuconfig instead of config. Or was it meant to be listed under Hardware I/O ports? It sure seems odd there to me. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/input/Kconfig |4 ++-- drivers/input/gameport/Kconfig |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) --- linux-2.6.23-rc8-mm1.orig/drivers/input/Kconfig +++ linux-2.6.23-rc8-mm1/drivers/input/Kconfig @@ -171,6 +171,8 @@ source "drivers/input/tablet/Kconfig" source "drivers/input/touchscreen/Kconfig" +source "drivers/input/gameport/Kconfig" + source "drivers/input/misc/Kconfig" endif @@ -179,8 +181,6 @@ menu "Hardware I/O ports" source "drivers/input/serio/Kconfig" -source "drivers/input/gameport/Kconfig" - endmenu endmenu --- linux-2.6.23-rc8-mm1.orig/drivers/input/gameport/Kconfig +++ linux-2.6.23-rc8-mm1/drivers/input/gameport/Kconfig @@ -1,8 +1,8 @@ # # Gameport configuration # -config GAMEPORT - tristate "Gameport support" +menuconfig GAMEPORT + bool "Gameport support" ---help--- Gameport support is for the standard 15-pin PC gameport. If you have a joystick, gamepad, gameport card, a soundcard with a gameport
Re: [PATCH 8/9] define global BIT macro
Jiri Slaby wrote: Randy Dunlap napsal(a): On Sat, 18 Aug 2007 11:44:12 +0200 (CEST) Jiri Slaby wrote: define global BIT macro move all local BIT defines to the new globally define macro. Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- include/linux/bitops.h |1 + include/video/sstfb.h |1 - include/video/tdfx.h|2 -- net/mac80211/ieee80211_i.h |2 -- 18 files changed, 1 insertions(+), 37 deletions(-) diff --git a/include/linux/bitops.h b/include/linux/bitops.h index 3255b06..a57b81f 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -3,6 +3,7 @@ #include #ifdef __KERNEL__ +#define BIT(nr)(1UL << (nr)) #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG)) #define BIT_WORD(nr) ((nr) / BITS_PER_LONG) #define BITS_TO_TYPE(nr, t)(((nr)+(t)-1)/(t)) So users of the BIT() macro in include/linux/input.h can be changed to use the global BIT_MASK() macro... and the former can be removed. I'm afraid I don't understand you. Maybe, you are writing about changes done in patch no. 7 [1], which didn't go through to the lkml? [1] http://www.fi.muni.cz/~xslaby/sklad/07-get-rid-of-input-bit-duplicate-defines.patch Exactly. Thanks. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
Re: [PATCH 8/9] define global BIT macro
On Sat, 18 Aug 2007 11:44:12 +0200 (CEST) Jiri Slaby wrote: > define global BIT macro > > move all local BIT defines to the new globally define macro. > > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> > > --- > > include/linux/bitops.h |1 + > include/video/sstfb.h |1 - > include/video/tdfx.h|2 -- > net/mac80211/ieee80211_i.h |2 -- > 18 files changed, 1 insertions(+), 37 deletions(-) > > diff --git a/include/linux/bitops.h b/include/linux/bitops.h > index 3255b06..a57b81f 100644 > --- a/include/linux/bitops.h > +++ b/include/linux/bitops.h > @@ -3,6 +3,7 @@ > #include > > #ifdef __KERNEL__ > +#define BIT(nr) (1UL << (nr)) > #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG)) > #define BIT_WORD(nr) ((nr) / BITS_PER_LONG) > #define BITS_TO_TYPE(nr, t) (((nr)+(t)-1)/(t)) So users of the BIT() macro in include/linux/input.h can be changed to use the global BIT_MASK() macro... and the former can be removed. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
