On Fri, 2007-05-25 at 16:12 -0700, Greg KH wrote: > On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote: > > Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's > > to blame: > > > > driver-core-check-return-code-of-sysfs_create_link.patch > > > > From: Cornelia Huck <[EMAIL PROTECTED]> > > > > Check for return value of sysfs_create_link() in device_add() and > > device_rename(). Add helper functions device_add_class_symlinks() and > > device_remove_class_symlinks() to make the code easier to read. > > {sigh} > > This wouldn't be the first time this patch has broken things :( > > Andrew, can you drop this from your tree? > > Cornelia, can you rework this to not break things?
Before we continue that road, we should define the expected behavior for the "cleanup" in error paths. Implementing that transaction-like model, to rewind a the complete device-creation when something like a symlink can't be created, may not always be the right thing to do. I think in most cases, we just want to write something like that to the error logs and continue, instead of letting a whole subsystem fail, or in the worst case, prevent the box from booting up. Thanks, Kay - 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/