[lkml]   [2019]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
+++ Matthew Dharm [04/09/19 09:16 -0700]:
>On Wed, Sep 4, 2019 at 5:12 AM Guenter Roeck <> wrote:
>> Note that I don't object to the patch set in general. There may be symbols
>> which only need be exported in the context of a single subsystem or even
>> driver (if a driver consists of more than one module). For example, a mfd
>> driver may export symbols which should only be called by its client drivers.
>> In such a situation, it may well be beneficial to limit the use of exported
>> symbols.
>I can appreciate this benefit.
>> I am not sure what good that does in practice (if I understand correctly,
>> a driver only has to declare that it wants to use a restricted use symbol
>> if it wants to use it), but that is a different question.
>I think this question implies that you are coming from the perspective
>of "security" or wanting to restrict access to the underlying
>functions, rather than wanting to clean-up the way symbols are handled
>for manageability / maintainability purposes (which is the goal, as I
>understand it).
>HOWEVER, I have one question: If these patches are included, and
>someone wants to introduce a bit of code which needs to use two
>symbols from different namespaces but with the same name, can that be
>done? That is, if driver A has symbol 'foo' and driver B has symbol
>'foo' (both in their respective namespaces), and driver C wants to use
> and, can that be supported?

As of now, we currently don't support this - modpost will warn if a
symbol is exported more than once (across modules + vmlinux), and the
module loader currently assumes exported symbol names are unique. Do
you have a concrete use case? If there is a strong need for this, I
don't think it'd be too hard to implement.



 \ /
  Last update: 2019-09-05 12:42    [W:0.106 / U:18.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site