Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp896179ybe; Wed, 4 Sep 2019 09:18:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqyv/e3AyQlh+wv16KihcowUby0i4JlX7nbXuN5sxkEMSyNUjmi7pgqhzrFOocT7BV44LlOl X-Received: by 2002:a17:902:9a41:: with SMTP id x1mr42492449plv.88.1567613885553; Wed, 04 Sep 2019 09:18:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567613885; cv=none; d=google.com; s=arc-20160816; b=a07yG3t1HPrhbtW32HdJ5cy1Hd9wdD1jvOQfqwNhgiM8y7ELCvbJ08cN4+vem0PGCf 5lQRNaND2ANhqQIWDU1YSJWWP2II/jpNJlGH3Ocqarf2pd99PDK58LANbkfZeEByJ/s9 zwqBt0TC0Na8YK4Xghr9jIelysxmhbI1IRoXq9zyWdNIkbBcYGWHm8wT6uB9oYIpuJCM jM4e17x8sAHzrKSiy/Ow7MN8Lf7VUMNfGSgK8X6ul63OzOfAiXEy5oJMbuUDb78Y4DxI YjsPH62fFoL7GC5PUlpMxCKeHxZZfJJflkdAL+L40RouQSVV/EErAzyX4bpzr7eTbP5a ipsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=3OkOI3j0Oo0CjA3trKCkMR2MwBR7d8kErbi/HKpfcyM=; b=vJ72/Xj89TVjiPIsm11TRgek5wFKiaBEuvoUXKEom/qxwfYr2U8//ItVJNvL+nHiRr BOHBshxjS4D49kRKQTETXUEK1X9ZkU7v7ZZPcXYCd0cYdO8NPZD3WdUMYM2pXTBpVMqY kTMGOweh3DHCMZ7+5WF4g0HqfprwJ+c7cCxVtzUL5ozT6HF7h63MUInSAqQACnd3PS1+ ZGIzaxk+709N2TsMP0+7ARnwas4RYvbAnCVBNYojpFuUsRLIajO6F/SX0a8c5bwGoEK8 R9mRX4eG8mpfR2IlhWHrJZpSzE5kPM0L+RFKishzWVrdPb8KiDi4Zl8Z46Y/R3E8ZMRW Te+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@one-eyed-alien.net header.s=google header.b=TUlK0rc1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q67si2692058pjq.42.2019.09.04.09.17.49; Wed, 04 Sep 2019 09:18:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@one-eyed-alien.net header.s=google header.b=TUlK0rc1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387800AbfIDQQZ (ORCPT + 99 others); Wed, 4 Sep 2019 12:16:25 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:36958 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387604AbfIDQQV (ORCPT ); Wed, 4 Sep 2019 12:16:21 -0400 Received: by mail-lj1-f196.google.com with SMTP id t14so20261406lji.4 for ; Wed, 04 Sep 2019 09:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=one-eyed-alien.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3OkOI3j0Oo0CjA3trKCkMR2MwBR7d8kErbi/HKpfcyM=; b=TUlK0rc196VsjDYABXU7yCCcQ4sTNOl47V6TQt/Z6Y4FZj6TevmCuFWT9dKCaAnTkd ii+pt9kyT4tMSieTNWDBUkxJWxisf3YEfmljgf/j7puwe7joaJGEU4O2426wowD5IuNU CQLeaZs18KcpY8ipXZwRFzvDYcdReO/oyNEP4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3OkOI3j0Oo0CjA3trKCkMR2MwBR7d8kErbi/HKpfcyM=; b=XEgDLyPu/SvN9NeKyYSdnLLj3yS+HpWX1119NHwIUU4FrLStfyUVEpd3tEC11xS6g0 AU1CMj0cZ5lyrRgsvrN+p+BbCCbu90mtKaCRq5m9n3E5Pn8svjYkj/cg8PCR+EXcUev9 UXe4niD6onUaUS4ml2jzQNRy7KJHpVoXawBITM30qVN9p3ZQpKQI8ArKIr48jr4vaTYd hxFq2uP+Ua8Lo1JanU+wC0pser8Ecn9uBsgHAp40qoDF1486C3sCWLRAfNYHlPYdIZzI 5usUsoenKt6FgiAlnhjkiWX/e5UJqbcic/u9R7AyMUci0cq8eQYq8MIGDoOSZEzarCOy /xqg== X-Gm-Message-State: APjAAAXiwB8SYTN1qRTuou8+aftc/K9iAXMN0IXprZzYRXdkVQCM7JMI Yeqt6Esyp/Hngn7mRZEq2En1DQhf9l99djSWuX4kkg== X-Received: by 2002:a2e:9ad4:: with SMTP id p20mr24178237ljj.49.1567613778648; Wed, 04 Sep 2019 09:16:18 -0700 (PDT) MIME-Version: 1.0 References: <20180716122125.175792-1-maco@android.com> <20190903150638.242049-1-maennich@google.com> <20190903150638.242049-13-maennich@google.com> <20190903161045.GA22754@roeck-us.net> In-Reply-To: From: Matthew Dharm Date: Wed, 4 Sep 2019 09:16:07 -0700 Message-ID: Subject: Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace To: Guenter Roeck Cc: Masahiro Yamada , Matthias Maennich , Linux Kernel Mailing List , "Cc: Android Kernel" , Arnd Bergmann , Greg Kroah-Hartman , Jessica Yu , "Joel Fernandes (Google)" , Lucas De Marchi , maco@android.com, sspatil@google.com, Will Deacon , Linux Kbuild mailing list , linux-modules@vger.kernel.org, linux-usb , USB Mass Storage on Linux , linux-watchdog@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 A.foo and B.foo, can that be supported? Matt -- Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux