From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84065C3A59E for ; Wed, 21 Aug 2019 14:59:24 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5A4FF22DA7 for ; Wed, 21 Aug 2019 14:59:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EIQbuWrN"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WLYmJXxA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A4FF22DA7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xnxq3o/GjOC/Gkq/QoUS92caEFL8JzumPzZHfXyq4Ig=; b=EIQbuWrNrpcpYm 5dOOnGtitAHX+QVut/b+obgKCh9kfwnwLY7r6e2XKaR1nWjvu81zeZmauWal1RRruhrJJLw7+tAFh TULTXXdzvxQYn8/kQF0afepVTGZZp5tW1Xl/wa59ETUJwuiCFw2yYGQ/ac2FgOGZU8/3qUeY2Co9e DTBeCQr6Z4KXqblaWQ3cUORTQgeu2Yyq6MB37RNG9Z1SENldUfyb4995y+EYCqOnGBunt17BFRDlE 4ZVQdeal7QRIhVSq6EALw2i012gsyQzOxU380H9XiIQHLxpI0gABG5Jb2M1cJT5o/a3jqM1ydYB+n Y4oa6pssC7N8xVD83/Jw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i0S50-0006nv-Mr; Wed, 21 Aug 2019 14:59:18 +0000 Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i0S4w-0006hr-1b; Wed, 21 Aug 2019 14:59:15 +0000 Received: by mail-pl1-x644.google.com with SMTP id d3so1486974plr.1; Wed, 21 Aug 2019 07:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MGu3Yx6P1oW2dkVZJ8rQOp/8pAXcm/B2IMgoDlOEKl4=; b=WLYmJXxArkZ+xpZrPWfZ85MRzNzUcKTIsk882+RxQxxR3Az/71RvVWigMyyc3o9qDg mtvIRNq6XqeN1cOcZdrxEKMDHffD2FSe6/WbeP3fCJsQQUwFHkNqyr1s3s/9l6wOl4hi i61XL/Ai4/XENarTcYSqmmmeNxx7hyK+c8wCDaxPxncIttf7Mf8ZvxfKx2BB2nHOHoC4 c0aMh+x4BaABVYpPLLtW5xg8u7M3ZX6mQoBFs4WrPYllZko4hPmPVVPlY8U86SnB4jfI OfGoENjS2m5V/qu3I2HjQjjnojwvAqezsZODeJIns7mWjTQGdm1PNzNZCvBa11J0X1NP 9Ryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=MGu3Yx6P1oW2dkVZJ8rQOp/8pAXcm/B2IMgoDlOEKl4=; b=uhbJ47o9sZ/RAqmyvpvgGJeZbs5qLnSljOAw9Ji4DvDsBQEQnDimO0hXyKXoz3eipI Atdxq5IcqlS8Macq2wPTThAQZHbEeZAhYDmyG48Jxzcwf1VlwH1MjRsxyfSGQARAhKSs crhzE61EwvebPnu4Yzl0BdQpek1a7dx1M0A9/1IZmLEz9X1nGNVzYIbHINSlyOp9DWrO oyFIA4l+E8QODZxafvGAAsd/SQri7/7ivzQC3046FXF77DzT5f0RKuXkEHonIr6IGR0l XfYhQbvJI5Nmew8Wghn4CCOjewV63oQtycSO0kJpGc+VhDDTT/USi41GO/9O1iB0+iXM YuaQ== X-Gm-Message-State: APjAAAVllDHJjtb6q3V7bfLYeXTjth0mnxgxI5cyeNKjZkjs9JY6tac4 7Q/DyAc/Zsu6voe5SWWsK4g= X-Google-Smtp-Source: APXvYqxUP8xkNyQZWYrRIamXP/wMkzF1WMKVh7TUKjSQXGKEymiVCjMrEbQg8CoUx7Bzq7phU6wEqA== X-Received: by 2002:a17:902:44f:: with SMTP id 73mr34838894ple.192.1566399552898; Wed, 21 Aug 2019 07:59:12 -0700 (PDT) Received: from localhost ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id m145sm27713891pfd.68.2019.08.21.07.59.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 07:59:12 -0700 (PDT) Date: Wed, 21 Aug 2019 07:59:11 -0700 From: Guenter Roeck To: Matthias Maennich Subject: Re: [PATCH v3 11/11] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace Message-ID: <20190821145911.GA6521@roeck-us.net> References: <20190813121733.52480-1-maennich@google.com> <20190821114955.12788-1-maennich@google.com> <20190821114955.12788-12-maennich@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190821114955.12788-12-maennich@google.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190821_075914_233095_4D9A1119 X-CRM114-Status: GOOD ( 22.19 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tomer Maimon , lucas.de.marchi@gmail.com, linux-stm32@st-md-mailman.stormreply.com, linux-arch@vger.kernel.org, linux-samsung-soc@vger.kernel.org, Kevin Hilman , Michal Simek , Ludovic Desroches , mingo@redhat.com, geert@linux-m68k.org, NXP Linux Team , Tomas Winkler , Jean Delvare , Sascha Hauer , tglx@linutronix.de, michal.lkml@markovi.net, Scott Branden , Andrew Jeffery , gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Pengutronix Kernel Team , Alexandre Belloni , linux-aspeed@lists.ozlabs.org, yamada.masahiro@socionext.com, Thierry Reding , Alexandre Torgue , Chunyan Zhang , Jonathan Hunter , Kukjin Kim , kernel-team@android.com, sspatil@google.com, linux-watchdog@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-arm-msm@vger.kernel.org, pombredanne@nexb.com, linux-m68k@lists.linux-m68k.org, linux-rpi-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, maco@android.com, linux-arm-kernel@lists.infradead.org, Barry Song , Johannes Thumshirn , oneukum@suse.com, Patrice Chotard , Stefan Wahren , Maxime Coquelin , kstewart@linuxfoundation.org, usb-storage@lists.one-eyed-alien.net, linux-tegra@vger.kernel.org, patches@opensource.cirrus.com, joel@joelfernandes.org, sam@ravnborg.org, linux-rtc@vger.kernel.org, Florian Fainelli , Benjamin Fair , Eric Anholt , Krzysztof Kozlowski , Nancy Yuen , Chen-Yu Tsai , bcm-kernel-feedback-list@broadcom.com, Joel Stanley , stern@rowland.harvard.edu, arnd@arndb.de, Ray Jui , Vladimir Zapolskiy , Orson Zhai , linux-hwmon@vger.kernel.org, Support Opensource , Andreas Werner , Avi Fishman , maco@google.com, jeyu@kernel.org, Shawn Guo , Baruch Siach , Mans Rullgard , Maxime Ripard , Jerry Hoemann , Tali Perry , hpa@zytor.com, linux-scsi@vger.kernel.org, openbmc@lists.ozlabs.org, x86@kernel.org, Andy Gross , Marc Gonzalez , William Breathitt Gray , linux-mediatek@lists.infradead.org, Fabio Estevam , Matthias Brugger , Wim Van Sebroeck , Alessandro Zummo , Baolin Wang , Patrick Venture , Nicolas Ferre , linux-modules@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org On Wed, Aug 21, 2019 at 12:49:26PM +0100, Matthias Maennich wrote: > Modules using these symbols are required to explicitly import the > namespace. This patch was generated with the following steps and serves > as a reference to use the symbol namespace feature: > > 1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols > in watchdog_core.c > 2) make (see warnings during modpost about missing imports) > 3) make nsdeps > > I used 'allmodconfig' for the above steps to ensure all occurrences are > patched. > > Defining DEFAULT_SYMBOL_NAMESPACE in the Makefile is not trivial in this > case as not only watchdog_core is defined in drivers/watchdog/Makefile. > Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros > to export into a different namespace. > I don't have the context, and thus I am missing the point of this patch set. Whatever it is supposed to accomplish, it seems extreme to me to require extra code in each driver for it. Anyway, WATCHDOG_CORE would be the default namespace (if it is what I think it is) for watchdog drivers, even though not all watchdog drivers use it. As such, I am missing an explanation why defining it in Makefile is not trivial. "... as not only watchdog_core is defined in drivers/watchdog/Makefile" does not mean anything to me and is not a real explanation. Also, it is not immediately obvious to me why "select WATCHDOG_CORE" in Kconfig would not automatically imply that WATCHDOG_CORE is used by a given driver, and why it is impossible to use that information to avoid the per-driver changes. I am also missing an explanation why WATCHDOG_CORE is going to be a separate namespace to start with. Maybe that discussion has happened, but I don't recall being advised or asked or told about it. Are we also going to have a new HWMON_CORE namespace ? And the same for each other subsystem in the kernel ? Since this is being added to the watchdog API, it will have to be documented accordingly. Watchdog driver writers, both inside and outside the watchdog subsystem, will need to know that they now have to add an additional boilerplate declaration into their drivers. Last but not least, combining patches affecting multiple subsystems in a single patch will make it difficult to apply and will likely result in conflicts. Personally I would prefer a split into one patch per affected subsystem. Also, please keep in mind that new pending watchdog drivers won't have the new boilerplate. Thanks, Guenter _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Date: Wed, 21 Aug 2019 07:59:11 -0700 Subject: [PATCH v3 11/11] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace In-Reply-To: <20190821114955.12788-12-maennich@google.com> References: <20190813121733.52480-1-maennich@google.com> <20190821114955.12788-1-maennich@google.com> <20190821114955.12788-12-maennich@google.com> Message-ID: <20190821145911.GA6521@roeck-us.net> List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Aug 21, 2019 at 12:49:26PM +0100, Matthias Maennich wrote: > Modules using these symbols are required to explicitly import the > namespace. This patch was generated with the following steps and serves > as a reference to use the symbol namespace feature: > > 1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols > in watchdog_core.c > 2) make (see warnings during modpost about missing imports) > 3) make nsdeps > > I used 'allmodconfig' for the above steps to ensure all occurrences are > patched. > > Defining DEFAULT_SYMBOL_NAMESPACE in the Makefile is not trivial in this > case as not only watchdog_core is defined in drivers/watchdog/Makefile. > Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros > to export into a different namespace. > I don't have the context, and thus I am missing the point of this patch set. Whatever it is supposed to accomplish, it seems extreme to me to require extra code in each driver for it. Anyway, WATCHDOG_CORE would be the default namespace (if it is what I think it is) for watchdog drivers, even though not all watchdog drivers use it. As such, I am missing an explanation why defining it in Makefile is not trivial. "... as not only watchdog_core is defined in drivers/watchdog/Makefile" does not mean anything to me and is not a real explanation. Also, it is not immediately obvious to me why "select WATCHDOG_CORE" in Kconfig would not automatically imply that WATCHDOG_CORE is used by a given driver, and why it is impossible to use that information to avoid the per-driver changes. I am also missing an explanation why WATCHDOG_CORE is going to be a separate namespace to start with. Maybe that discussion has happened, but I don't recall being advised or asked or told about it. Are we also going to have a new HWMON_CORE namespace ? And the same for each other subsystem in the kernel ? Since this is being added to the watchdog API, it will have to be documented accordingly. Watchdog driver writers, both inside and outside the watchdog subsystem, will need to know that they now have to add an additional boilerplate declaration into their drivers. Last but not least, combining patches affecting multiple subsystems in a single patch will make it difficult to apply and will likely result in conflicts. Personally I would prefer a split into one patch per affected subsystem. Also, please keep in mind that new pending watchdog drivers won't have the new boilerplate. Thanks, Guenter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [PATCH v3 11/11] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace Date: Wed, 21 Aug 2019 07:59:11 -0700 Message-ID: <20190821145911.GA6521@roeck-us.net> References: <20190813121733.52480-1-maennich@google.com> <20190821114955.12788-1-maennich@google.com> <20190821114955.12788-12-maennich@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20190821114955.12788-12-maennich-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+glpam-linux-mediatek=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Matthias Maennich Cc: Tomer Maimon , lucas.de.marchi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-stm32-XDFAJ8BFU24N7RejjzZ/Li2xQDfSxrLKVpNB7YpNyf8@public.gmane.org, linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kevin Hilman , Michal Simek , Ludovic Desroches , mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org, NXP Linux Team , Tomas Winkler , Jean Delvare , Sascha Hauer , tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, michal.lkml-yyZNWGI4GtDR7s880joybQ@public.gmane.org, Scott Branden , Andrew Jeffery , gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pengutronix Kernel Team , Alexandre Belloni , linux-aspeed-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org, Thierry Reding List-Id: linux-arch.vger.kernel.org On Wed, Aug 21, 2019 at 12:49:26PM +0100, Matthias Maennich wrote: > Modules using these symbols are required to explicitly import the > namespace. This patch was generated with the following steps and serves > as a reference to use the symbol namespace feature: > > 1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols > in watchdog_core.c > 2) make (see warnings during modpost about missing imports) > 3) make nsdeps > > I used 'allmodconfig' for the above steps to ensure all occurrences are > patched. > > Defining DEFAULT_SYMBOL_NAMESPACE in the Makefile is not trivial in this > case as not only watchdog_core is defined in drivers/watchdog/Makefile. > Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros > to export into a different namespace. > I don't have the context, and thus I am missing the point of this patch set. Whatever it is supposed to accomplish, it seems extreme to me to require extra code in each driver for it. Anyway, WATCHDOG_CORE would be the default namespace (if it is what I think it is) for watchdog drivers, even though not all watchdog drivers use it. As such, I am missing an explanation why defining it in Makefile is not trivial. "... as not only watchdog_core is defined in drivers/watchdog/Makefile" does not mean anything to me and is not a real explanation. Also, it is not immediately obvious to me why "select WATCHDOG_CORE" in Kconfig would not automatically imply that WATCHDOG_CORE is used by a given driver, and why it is impossible to use that information to avoid the per-driver changes. I am also missing an explanation why WATCHDOG_CORE is going to be a separate namespace to start with. Maybe that discussion has happened, but I don't recall being advised or asked or told about it. Are we also going to have a new HWMON_CORE namespace ? And the same for each other subsystem in the kernel ? Since this is being added to the watchdog API, it will have to be documented accordingly. Watchdog driver writers, both inside and outside the watchdog subsystem, will need to know that they now have to add an additional boilerplate declaration into their drivers. Last but not least, combining patches affecting multiple subsystems in a single patch will make it difficult to apply and will likely result in conflicts. Personally I would prefer a split into one patch per affected subsystem. Also, please keep in mind that new pending watchdog drivers won't have the new boilerplate. Thanks, Guenter From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::642; helo=mail-pl1-x642.google.com; envelope-from=groeck7@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="WLYmJXxA"; dkim-atps=neutral Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46D9mN31RqzDqy9; Thu, 22 Aug 2019 00:59:16 +1000 (AEST) Received: by mail-pl1-x642.google.com with SMTP id c2so1460694plz.13; Wed, 21 Aug 2019 07:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MGu3Yx6P1oW2dkVZJ8rQOp/8pAXcm/B2IMgoDlOEKl4=; b=WLYmJXxArkZ+xpZrPWfZ85MRzNzUcKTIsk882+RxQxxR3Az/71RvVWigMyyc3o9qDg mtvIRNq6XqeN1cOcZdrxEKMDHffD2FSe6/WbeP3fCJsQQUwFHkNqyr1s3s/9l6wOl4hi i61XL/Ai4/XENarTcYSqmmmeNxx7hyK+c8wCDaxPxncIttf7Mf8ZvxfKx2BB2nHOHoC4 c0aMh+x4BaABVYpPLLtW5xg8u7M3ZX6mQoBFs4WrPYllZko4hPmPVVPlY8U86SnB4jfI OfGoENjS2m5V/qu3I2HjQjjnojwvAqezsZODeJIns7mWjTQGdm1PNzNZCvBa11J0X1NP 9Ryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=MGu3Yx6P1oW2dkVZJ8rQOp/8pAXcm/B2IMgoDlOEKl4=; b=ilhisAh4BQgDAEa8wJitFG7bimupAj/uwLqVLa83XjJNswHnydYDM51pOMpgf5jXpG Zkfr3CntZSEUGNm2CA/BjSzOAJ+f6w9WIXkSFUP3zfNmvzMvJBvEuAfZh3KA6y9LFzs1 KTFGLcfYoAo8i/2pD1XLhksOLBijUe4mQtANqeRVO0mvnFdbP+HQ+lA12CGqWafQCQWr d9iPgyfphvnZGaECI/vk4DA3fpfkpn4iYBRGpYb/S/N3RjL1nXXrm/qTqGEB67EVRdQp 4zt5ZiDEoW6tDy0d4k3SfuvV8sIA+3TNbYmPb9Pz7kaht3SQxXNWiPsYbUHbcyWu3+Kx YafQ== X-Gm-Message-State: APjAAAU/ETJ2hgIzVzcvya/+uA0bQgjPFH5sNdPnrH/klJrn9l6MCTVa 7HKGiyyzpcUA5nnRpVyiHYI= X-Google-Smtp-Source: APXvYqxUP8xkNyQZWYrRIamXP/wMkzF1WMKVh7TUKjSQXGKEymiVCjMrEbQg8CoUx7Bzq7phU6wEqA== X-Received: by 2002:a17:902:44f:: with SMTP id 73mr34838894ple.192.1566399552898; Wed, 21 Aug 2019 07:59:12 -0700 (PDT) Received: from localhost ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id m145sm27713891pfd.68.2019.08.21.07.59.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 07:59:12 -0700 (PDT) Sender: Guenter Roeck Date: Wed, 21 Aug 2019 07:59:11 -0700 From: Guenter Roeck To: Matthias Maennich Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, arnd@arndb.de, geert@linux-m68k.org, gregkh@linuxfoundation.org, hpa@zytor.com, jeyu@kernel.org, joel@joelfernandes.org, kstewart@linuxfoundation.org, linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-modules@vger.kernel.org, linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org, lucas.de.marchi@gmail.com, maco@android.com, maco@google.com, michal.lkml@markovi.net, mingo@redhat.com, oneukum@suse.com, pombredanne@nexb.com, sam@ravnborg.org, sspatil@google.com, stern@rowland.harvard.edu, tglx@linutronix.de, usb-storage@lists.one-eyed-alien.net, x86@kernel.org, yamada.masahiro@socionext.com, Jean Delvare , Alessandro Zummo , Alexandre Belloni , Wim Van Sebroeck , Joel Stanley , Andrew Jeffery , Nicolas Ferre , Ludovic Desroches , Eric Anholt , Stefan Wahren , Florian Fainelli , Ray Jui , Scott Branden , bcm-kernel-feedback-list@broadcom.com, Support Opensource , Baruch Siach , William Breathitt Gray , Jerry Hoemann , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Vladimir Zapolskiy , Tomas Winkler , Johannes Thumshirn , Andreas Werner , Kevin Hilman , Matthias Brugger , Avi Fishman , Tomer Maimon , Tali Perry , Patrick Venture , Nancy Yuen , Benjamin Fair , Michal Simek , Andy Gross , Kukjin Kim , Krzysztof Kozlowski , Barry Song , Orson Zhai , Baolin Wang , Chunyan Zhang , Patrice Chotard , Maxime Coquelin , Alexandre Torgue , Maxime Ripard , Chen-Yu Tsai , Marc Gonzalez , Mans Rullgard , Thierry Reding , Jonathan Hunter , linux-hwmon@vger.kernel.org, linux-rtc@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-rpi-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-mediatek@lists.infradead.org, openbmc@lists.ozlabs.org, linux-arm-msm@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-tegra@vger.kernel.org, patches@opensource.cirrus.com Subject: Re: [PATCH v3 11/11] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace Message-ID: <20190821145911.GA6521@roeck-us.net> References: <20190813121733.52480-1-maennich@google.com> <20190821114955.12788-1-maennich@google.com> <20190821114955.12788-12-maennich@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190821114955.12788-12-maennich@google.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Mailman-Approved-At: Mon, 02 Sep 2019 10:34:52 +1000 X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 14:59:16 -0000 On Wed, Aug 21, 2019 at 12:49:26PM +0100, Matthias Maennich wrote: > Modules using these symbols are required to explicitly import the > namespace. This patch was generated with the following steps and serves > as a reference to use the symbol namespace feature: > > 1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols > in watchdog_core.c > 2) make (see warnings during modpost about missing imports) > 3) make nsdeps > > I used 'allmodconfig' for the above steps to ensure all occurrences are > patched. > > Defining DEFAULT_SYMBOL_NAMESPACE in the Makefile is not trivial in this > case as not only watchdog_core is defined in drivers/watchdog/Makefile. > Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros > to export into a different namespace. > I don't have the context, and thus I am missing the point of this patch set. Whatever it is supposed to accomplish, it seems extreme to me to require extra code in each driver for it. Anyway, WATCHDOG_CORE would be the default namespace (if it is what I think it is) for watchdog drivers, even though not all watchdog drivers use it. As such, I am missing an explanation why defining it in Makefile is not trivial. "... as not only watchdog_core is defined in drivers/watchdog/Makefile" does not mean anything to me and is not a real explanation. Also, it is not immediately obvious to me why "select WATCHDOG_CORE" in Kconfig would not automatically imply that WATCHDOG_CORE is used by a given driver, and why it is impossible to use that information to avoid the per-driver changes. I am also missing an explanation why WATCHDOG_CORE is going to be a separate namespace to start with. Maybe that discussion has happened, but I don't recall being advised or asked or told about it. Are we also going to have a new HWMON_CORE namespace ? And the same for each other subsystem in the kernel ? Since this is being added to the watchdog API, it will have to be documented accordingly. Watchdog driver writers, both inside and outside the watchdog subsystem, will need to know that they now have to add an additional boilerplate declaration into their drivers. Last but not least, combining patches affecting multiple subsystems in a single patch will make it difficult to apply and will likely result in conflicts. Personally I would prefer a split into one patch per affected subsystem. Also, please keep in mind that new pending watchdog drivers won't have the new boilerplate. Thanks, Guenter