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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
