Tejun Heo <tj@xxxxxxxxxx> writes: > On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote: >> I think this is being blown out of proportion. It was a rarely used >> API and converting to the new one is mostly trivial which can be > > 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. I had a quick look too and this seems correct (at least if my reading on howto use sysfs APIs is correct). I'm happy to post a patch somewhere - I guess it's easiest if the removal waits for one linus merge things cycle and then I can get fix and removal in? I'm not too fussed. > 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. I use an API and it changes/disappears - it's a gift I have :) -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
