On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote: > On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/ > > > > > > - Lots of fixes, updates and cleanups all over the place. > > > > > > - If you have the right debugging options set, this kernel will generate > > > a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. > > > It is being worked on. > > > > > > > > > Changes since 2.6.13-rc5-mm1: > > > [...] > > > +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch > > > [...] > > > > > > it broke loading of firmware for me.(dmesg was flooded with > > "firmware_loading_store: unexpected value (0)") > > > > firmware.agent uses echo so there is a trailing newline. If i changes > > firmware.agent to uses echo -n it works correctly. > > > > Is this a bug or the correct behaviour ? > > Somewhere there is a mistake in the white space processing code of the > firmware driver. Before this patch we had inconsistent handling of > whitespace and sysfs attributes. This patch forces it to be consistent > and will shake out all of the places in the drivers where it is > handled wrong. Sysfs attributes are now stripped of leading and > trailing white space before being handed to the device driver.
ok, i found it. If i do echo 1, it will read '1\n', will remove the '\n' and send '1' to ops->store. Then it will re-read '\n' and send '' to ops->store. And it will loop... Maybe sysfs should return the old count instead of ops->store ? > > Fbdev sysfs attributes are also broken for white space handling and > need to be fixed. Overall the patch should be correct and it is the > drivers that are broken. > Regards, Benoit Boissinot -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - 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/