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