From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751854AbdGEPRb (ORCPT ); Wed, 5 Jul 2017 11:17:31 -0400 Received: from verein.lst.de ([213.95.11.211]:54975 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751707AbdGEPRa (ORCPT ); Wed, 5 Jul 2017 11:17:30 -0400 Date: Wed, 5 Jul 2017 17:17:28 +0200 From: Christoph Hellwig To: Tomasz Figa Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Marek Szyprowski , Robin Murphy , Greg Kroah-Hartman , Joerg Roedel , Will Deacon , Vineet Gupta , Hans-Christian Noren Egtvedt , Mitchel Humpherys , Krzysztof Kozlowski , Arnd Bergmann Subject: Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Message-ID: <20170705151728.GA2479@lst.de> References: <20170705071215.17603-1-tfiga@chromium.org> <20170705071215.17603-2-tfiga@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170705071215.17603-2-tfiga@chromium.org> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Please use EXPORT_SYMBOL_GPL for any of these exports, as they are internal linux implementration details by any definition of it. On Wed, Jul 05, 2017 at 04:12:11PM +0900, Tomasz Figa wrote: > There is nothing wrong in having a loadable module implementing DMA API, > for example to be used for sub-devices registered by the module. > However, most of the functions from dma-mapping do not have their > symbols exported, making it impossible to use them from loadable modules. I'd like to see the patches for this use case as well. We don't generally export symbols without seeing the users. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Date: Wed, 5 Jul 2017 17:17:28 +0200 Message-ID: <20170705151728.GA2479@lst.de> References: <20170705071215.17603-1-tfiga@chromium.org> <20170705071215.17603-2-tfiga@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170705071215.17603-2-tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Tomasz Figa Cc: Arnd Bergmann , Greg Kroah-Hartman , Will Deacon , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Krzysztof Kozlowski , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Vineet Gupta , Hans-Christian Noren Egtvedt , Christoph Hellwig List-Id: iommu@lists.linux-foundation.org Please use EXPORT_SYMBOL_GPL for any of these exports, as they are internal linux implementration details by any definition of it. On Wed, Jul 05, 2017 at 04:12:11PM +0900, Tomasz Figa wrote: > There is nothing wrong in having a loadable module implementing DMA API, > for example to be used for sub-devices registered by the module. > However, most of the functions from dma-mapping do not have their > symbols exported, making it impossible to use them from loadable modules. I'd like to see the patches for this use case as well. We don't generally export symbols without seeing the users.