[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080916074802.200c8a43@infradead.org>
Date: Tue, 16 Sep 2008 07:48:02 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Adrian Bunk <bunk@...nel.org>
Cc: Theodore Tso <tytso@....edu>, Jarek Poplawski <jarkao2@...il.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
David Miller <davem@...emloft.net>, jeff@...zik.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [git patches] net driver fixes
On Tue, 16 Sep 2008 17:34:10 +0300
Adrian Bunk <bunk@...nel.org> wrote:
> On Tue, Sep 16, 2008 at 07:02:41AM -0700, Arjan van de Ven wrote:
> > On Tue, 16 Sep 2008 09:54:08 -0400
> > Theodore Tso <tytso@....edu> wrote:
> >
> > > If it's a really important bug, and it affects a huge number of
> > > users, or it's really bad security bug, the reality is that
> > > exceptions will be made to the rules. But exceptions need to
> > > remain exceptions for extraordinary situations, not everyday
> > > occurrences. And of course, if the bug does affect a huge number
> > > of users, someone should be asking the question why it wasn't
> > > detected sooner, say before the last merge window --- and to ask
> > > the question how many users is this bug really going to affect
> > > anyway?
> > >
> > > At least, that's my take on things,
> > >
> >
> > also note that Linus said "regression or on the kerneloops list";
> > if it has any kind of backtrace, it'll be there if it's a common
> > problem that hits many users.
>
> Thomas' patch [1] will fixes a bug of a kind that will likely never
> make it to your list.
not sure; just we need to catch doing pci_disable_device on a
non-enabled device as a WARN_ON.
and the patch looks quite wrong, the real answer should be to do the
enable in open() :-)
>
> And the same also e.g. goes for bugs where your machine is completely
> dead (no SysRq possible) with nothing in the logs.
that's being worked on, by storing the crash data in some non-volatile
piece of memory
>
> The kerneloops lists are quite valuable, but they can never cover all
> classes of fatal bugs.
if you want perfection, you're not going to get it.
"Perfect is the enemy of good"
If you want to help make things better (as opposed to perfect), you're
very welcome to help out, be it with suggestions on how to improve
or with actual code.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists