Re: [git patches] two warning fixes

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2007-07-18 at 20:05 -0400, Jeff Garzik wrote:
> Andi Kleen wrote:
> > On Thursday 19 July 2007 01:55:04 Jeff Garzik wrote:
> >> Please pull from 'warnings' branch of
> >> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git warnings
> >>
> >> to receive the following updates:
> >>
> >>  drivers/video/aty/radeon_base.c |   23 ++++++++++++++++++-----
> >>  include/asm-x86_64/tlbflush.h   |    6 +++++-
> >>  2 files changed, 23 insertions(+), 6 deletions(-)
> >>
> >> Jeff Garzik (2):
> >>       drivers/video/aty/radeon_base: fix radeonfb_pci_register() err handling
> >>       [X86-64] make flush_tlb_kernel_range() a static inline function
> > 
> > I already got that patch queued. Why don't you send them through the maintainers?
> 
> Because in both cases the maintainers never responded to me, indicating 
> they were queued?

I suppose I should have acked the radeonfb one... I'm a bit of a slacker
with radeonfb maintainership lately.

However, in this case, I think I'll NACK it. I don't think it's fair to
fail the fb initialization because it couldn't create the EDID files. A
warning in dmesg is enough. For lots of machines, failing the fb init
means no console at all...

In general, I share paulus point of view here that forcing us to test
all those result code from sysfs file creation functions is just a major
PITA and adds bloat all over the kernel. There are many many cases where
the "obvious" thing of erroring out is actually not good policy. In many
cases, the failure to create some random sysfs file shouldn't prevent
the driver from operating, because the consequences of doing the later
are worse than the consequences of not having that sysfs file in the
first place. Thus, warnings are a better thing to do. But multiply the
number of sysfs_* calls by the code size of adding a test & printk and
you'll get the direct non-configurable-out bloat to the kernel.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/