[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100517193840.GB14047@gandalf>
Date: Mon, 17 May 2010 22:38:40 +0300
From: Felipe Balbi <me@...ipebalbi.com>
To: James Bottomley <James.Bottomley@...e.de>
Cc: me@...ipebalbi.com, Kevin Hilman <khilman@...prootsystems.com>,
Alan Stern <stern@...land.harvard.edu>,
linux-omap@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
Geoff Smith <geoffx.smith@...el.com>,
Brian Swetland <swetland@...gle.com>,
Kernel development list <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Tejun Heo <tj@...nel.org>,
Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Liam Girdwood <lrg@...mlogic.co.uk>,
Matthew Garrett <mjg@...hat.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
Hi,
On Mon, May 17, 2010 at 03:24:27PM -0400, James Bottomley wrote:
> Surely, depending on your UART FIFO depth, of course, a serial console
> interrupts once every 16 characters or so ... how do you filter out that
> storm of interrupts refreshing the powertop screen from the actual
> application problems?
>
> But anyway, the average user probably either doesn't have or doesn't
> know how to get to a serial console on their phone ...
like I said: use a big memory buffer and print to that. Only flush after
you're done profiling. Something like dmesg.
> If you actually s/app/USB storage device/ (with a few other obvious text
> changes) in most of the above two paragraphs, you've got a good
> description of the problems we go through on an almost daily basis in
> the kernel for USB storage ... and why we've grown a massive exception
> table.
>
> Just saying "devices should conform to specifications" is a wonderful
> magic wand for wishing away all the problems bad devices cause and
> bludgeoning manufacturers with the said spec wrapped around a large lead
> brick is very cathartic but it doesn't change the fact that users blame
> the kernel for not working with the bad devices ... and we gave up
> trying to re-educate users on that score years ago.
that's a whole other story. Hardware issues are things which in 99.999%
of the cases we can't change. We have to work around them. Software
bugs, on the other hand, can be fixed much more easily. I'm sure you
agree with that, don't you ?
Trying to make a comparisson between hardware bug and software bug is
simply non-sense in this case.
--
balbi
--
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