Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+++ Matthew Dharm [04/09/19 09:16 -0700]:
On Wed, Sep 4, 2019 at 5:12 AM Guenter Roeck <linux@xxxxxxxxxxxx> 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
A.foo and B.foo, 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.

Thanks,

Jessica




[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux