On Tue, 2016-03-08 at 15:31 -0800, Linus Torvalds wrote: > On Tue, Mar 8, 2016 at 4:04 PM, Toshi Kani <toshi.kani@xxxxxxx> wrote: > > > > Yes, I prefer the devm semantics. insert_resource() and > > remove_resource() are not exported interfaces. So, with > > devm_add_action(), we still need to introduce built-in exported > > wrappers for insert/remove_resource(), unless we change to export them > > directly. Since we need to export "something", I think it is better to > > export their devm interfaces. > > So I'm coming from the background that > > (a) less code is better > > (b) the "devm_" interface may be convenient, but it has also > traditionally also been a cause of problems and limitations. > > Now, the main problems with the devm interface has been either > ordering (which just isn't an issue with resource allocation - it's > been an issue with irqs) or the fact that it can't always be used if > you're not in the right context. So it's "convenient but potentially > inflexible". > > And the thing is, I think convenience functions mainly make sense for > places where there are multiple users. If there really is just one or > two (number completely pulled out of my ass), I don't see the point of > a "convenience" function, when we've had the main actual _code_ > functionality for over a decade. > > So unless there are more users, I'd suggest just exporting the > insert_resource function. > > We already export allocate_resource and adjust_resource. > > Now, the _one_ argument for devm_insert_resource() is that we do have > "devm_request_resource()". > > But quite frankly, just counting the number of devm_request_resource() > calls weakens that argument. There's 7 callers in the whole kernel. > The regular "request_resource()" has 200+ callers. > > That may be due to historical reasons, but it may also be at least > partially due to (b) above - there are a number of cases where the > "devm_xyz()" model doesn't work well. > > So I think we should see the "devm_xyz()" forms as being a "let's make > things easy for driver writers". I do _not_ think it makes sense for > one-off users. > > Now, if it turns out that there are lots of other potential users of > devm_insert_resource(), that would maks all of my arguments go away. I agree that there won't be many users of devm_insert_resource(). So, I am going to export insert_resource() and remove_resource() as you suggested, and let the NFIT driver to call them using devm_add_action() as a one-off solution. Thanks! -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
