lkml.org 
[lkml]   [2016]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2-UPDATE2 3/4] resource: Add device-managed insert/remove_resource()
From
Date
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@hpe.com> 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

\
 
 \ /
  Last update: 2016-03-09 01:41    [W:0.053 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site