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.
Linus
--
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
