From: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
Matthias Maennich <maennich@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Cc: Android Kernel" <kernel-team@android.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jessica Yu <jeyu@kernel.org>,
"Joel Fernandes (Google)" <joel@joelfernandes.org>,
Lucas De Marchi <lucas.de.marchi@gmail.com>,
maco@android.com, sspatil@google.com,
Will Deacon <will@kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
linux-modules@vger.kernel.org,
linux-usb <linux-usb@vger.kernel.org>,
USB Mass Storage on Linux <usb-storage@lists.one-eyed-alien.net>,
linux-watchdog@vger.kernel.org
Subject: Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
Date: Wed, 4 Sep 2019 09:16:07 -0700 [thread overview]
Message-ID: <CAA6KcBBeP9xYbVws4=RMFNA4kyrodE-R3mifhbkee-Q+jFRcoQ@mail.gmail.com> (raw)
In-Reply-To: <c6ac941c-06a4-e5dc-5cb9-fca7b40d7e9a@roeck-us.net>
On Wed, Sep 4, 2019 at 5:12 AM Guenter Roeck <linux@roeck-us.net> 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?
Matt
--
Matthew Dharm
Former Maintainer, USB Mass Storage driver for Linux
next prev parent reply other threads:[~2019-09-04 16:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180716122125.175792-1-maco@android.com>
2019-09-03 15:06 ` [PATCH v4 00/12] Symbol Namespaces Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 01/12] module: support reading multiple values per modinfo tag Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 02/12] export: explicitly align struct kernel_symbol Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 03/12] module: add support for symbol namespaces Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 04/12] modpost: " Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 05/12] module: add config option MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 06/12] export: allow definition default namespaces in Makefiles or sources Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 07/12] modpost: add support for generating namespace dependencies Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 08/12] scripts: Coccinelle script for " Matthias Maennich
2019-09-04 9:53 ` Masahiro Yamada
2019-09-05 14:46 ` Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 09/12] docs: Add documentation for Symbol Namespaces Matthias Maennich
2019-09-04 7:16 ` Greg KH
2019-09-03 15:06 ` [PATCH v4 10/12] usb-storage: remove single-use define for debugging Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 11/12] RFC: usb-storage: export symbols in USB_STORAGE namespace Matthias Maennich
2019-09-03 15:06 ` [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace Matthias Maennich
2019-09-03 16:10 ` Guenter Roeck
2019-09-04 8:45 ` Masahiro Yamada
2019-09-04 12:12 ` Guenter Roeck
2019-09-04 16:16 ` Matthew Dharm [this message]
2019-09-05 10:41 ` [usb-storage] " Jessica Yu
2019-09-05 10:52 ` Arnd Bergmann
2019-09-05 11:16 ` Jessica Yu
2019-09-05 11:25 ` Masahiro Yamada
2019-09-05 12:00 ` Greg Kroah-Hartman
2019-09-05 11:25 ` Matthias Maennich
2019-09-04 9:37 ` [PATCH v4 00/12] Symbol Namespaces Masahiro Yamada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA6KcBBeP9xYbVws4=RMFNA4kyrodE-R3mifhbkee-Q+jFRcoQ@mail.gmail.com' \
--to=mdharm-usb@one-eyed-alien.net \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=jeyu@kernel.org \
--cc=joel@joelfernandes.org \
--cc=kernel-team@android.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lucas.de.marchi@gmail.com \
--cc=maco@android.com \
--cc=maennich@google.com \
--cc=sspatil@google.com \
--cc=usb-storage@lists.one-eyed-alien.net \
--cc=will@kernel.org \
--cc=yamada.masahiro@socionext.com \
--subject='Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).