Re: linux-next: build failure after merge of the driver-core tree

From: Benjamin Herrenschmidt
Date: Mon Mar 17 2014 - 20:22:53 EST


On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote:
> So, looked at the failed code. The only necessary change seems to be
> calling device_remove_file_self() in dump_ack_store() and then doing
> kobject_put() directly afterwards, which would have been completely
> fine as a merge fix patch.

Ok. Since there's no merge error, I'll have to tell Linus explicitly to
apply it during the merge. I've never done that before but I suppose
it's doable.

> Just to be clear, I'm not necessarily against reverting the removal of
> the API. The removal was based on the speculation that this isn't
> likely to cause trouble. The speculation was perfectly reasonable but
> being a speculation it failed, so we take actions to remedy that and
> we *do* want to do things that way. Reverting the removal can sure be
> one choice but the way that choice is being made here seems completely
> wrong to me. There's no technical evaluation whatsoever. I'd really
> hate to work in an environment where taking active trade off is
> discouraged replaced with blind policy enforcement.

Sorry I don't understand. Reverting the removal until after -rc1 (or
later in the merge window) is the easiest path from my perspective and
ensure no bisection breakage but whatever Linus prefers works here.

I don't think it's a drastic action or anything like that. It can
trivially be re-applied once the merge window has settled. But I'm happy
to also just send Linus a "apply this as a merge fixup" patch if he's
happy with the method (as I said, I've never done that before on
something that doesn't have an actual merge conflict to begin with)

Cheers,
Ben.


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