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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
