Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp996141ybb; Fri, 20 Mar 2020 11:31:27 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsdO73j3JXiXqRtEjQwKzd0DLRxI28S3qvOyrzQlzkElNRC6gDxSDrOUhJTcr6/TsoO5Gx8 X-Received: by 2002:aca:4142:: with SMTP id o63mr7407165oia.118.1584729087160; Fri, 20 Mar 2020 11:31:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584729087; cv=none; d=google.com; s=arc-20160816; b=gRkIrPxOi+WGpd0bTC7fOHq8RqLPPr1oNtmNWk/wpVpC1vdto3CRqVCvhcQ6GsaNCX DrQbYCq8/HDP2rg6KUUpJfLdj0wKZAtAWeev8OZl6HetHCHZknnkHfEFva/Tt7adMzqu J9rQTqLIdvDKA9NZcs9tgJf92uGvZWokcsrvUFBs5hZUj2yBiUA73HAuJS4daE2lAQud uDxzeTNEY1tIAuyY6od2nAGD/F1Z9cEW004g92lny3nA+sRdydnGkXNxjHhZoO5dtutP /Lqh5xw4P0aar5j6J8myeGrjKt98cAOydreeGXF99agR70CY2Ah/MvmhwovWDdXxT+OB 5Iqw== 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=YfCEg6jyW4rMddIRvWAX/VKW3u1IK74f94P15G8A+YU=; b=a1fu8vY3qIMXc91/REs1QQNZPKolI0lkKDi6sXyc1izxBSd+mEYOVSWV4yUsauk/ak zILaj/A2JlRx0JDpJueXMPHkLxSkd1YdsRFuv6nm//9VL/0CT222m1KypMeCzFOFEohJ z/zsOcZ6P2UuNn3rI9Q69pJUY3lUQXGGnXHUmnMXrqItoO1yXyq6HDSGm2AtiiyWc5M8 MQujZJpyfYjAWUrtr5MqSLL348O1/Xj+qcaRrEQpLJvfP0+7DgJTKwTVSCRjWNUnHSXf /MaY72JUMyEm+on6LWT7+oOFcs+wOQkqWxlPK0PMtH8LMyqUO9OnNIa/Q6+g1Zl77QJa 8TLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NG+ISksH; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s15si3110091oie.175.2020.03.20.11.31.11; Fri, 20 Mar 2020 11:31:27 -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=@gmail.com header.s=20161025 header.b=NG+ISksH; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726829AbgCTSas (ORCPT + 99 others); Fri, 20 Mar 2020 14:30:48 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:44651 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726773AbgCTSar (ORCPT ); Fri, 20 Mar 2020 14:30:47 -0400 Received: by mail-lf1-f65.google.com with SMTP id j188so1496933lfj.11 for ; Fri, 20 Mar 2020 11:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YfCEg6jyW4rMddIRvWAX/VKW3u1IK74f94P15G8A+YU=; b=NG+ISksHKXiylTdpQtYPaHtiWBMaj0a6ivrgsEw1vCx9CdXSMGh/AZYOUFGgYyLjvL VCUmyYUGNCOXWpb0UyRcoUPCp6M6SlxkpwgmMI1pimhiOdMqfUYsn7uad2MvWodnoV6z GfaSDoy9kJQV0lMAZifJQ1VEeQCa4n6laTHFRNDMCVs1muuMwU51JeShye2JP9XiW0Ut R66bTaWHLKNhQlRy/P6TjshxrDcqk4NYp+PkJm+zc+9iJeeTVJMsR3tCZHlAm2+5L/6A IW0xPiyI43UVSltCEQGPPJUedLFm6QOgK7XfWEfv7lx0oILQnQzxpGsLUMEEGfOEsjpO 0U9Q== 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=YfCEg6jyW4rMddIRvWAX/VKW3u1IK74f94P15G8A+YU=; b=AxRAZNSaD0Azxe94FQ56uMTPQiMFagu8yH8u0o0HcuEJjix57FxQhDPIVmlkkk8Uzw HKC9gXISK0/Nl54j9+8v7SJ7jPcbz8/HtxF1K4d/AIjbQXDvFRqbB4q9TF5WIognuAy3 walZIqEcOYNwV1FI/UK0dpkPNZ7DXaYTs/efAM3pj0fC0EaaIIESqE1UJ2NBAoLNMWqj mciBuBMkdT2Xdt1aylOpp3cg1DMWOqXJfbZr6u6wL+OTohlJqyyNsL956HhzKbaz9jpf s6uy2E22wsjlvmDANpkIvazcxfH4xHbfM9KJwYys5KGy4wBmKNr0yuqNFRnBm4am7U6+ YYEw== X-Gm-Message-State: ANhLgQ2Rm/SRy636RE5u5DEfmqcxeXSJT2vQL5wWAzPR43uJWrN2k7fc xcO0vSTKdNirIFepI3re7Rmp/+6dEk7sBf7VbB8= X-Received: by 2002:ac2:4c13:: with SMTP id t19mr1532513lfq.16.1584729043191; Fri, 20 Mar 2020 11:30:43 -0700 (PDT) MIME-Version: 1.0 References: <1584558186-23373-1-git-send-email-orson.unisoc@gmail.com> <51568376-da8b-3265-ddb3-6ddba74207dc@akamai.com> <20200319152820.GA2793@lenovo> In-Reply-To: From: Orson Zhai Date: Sat, 21 Mar 2020 02:30:31 +0800 Message-ID: Subject: Re: [RFC PATCH] dynamic_debug: Add config option of DYNAMIC_DEBUG_CORE To: Jason Baron Cc: Andrew Morton , Changbin Du , Randy Dunlap , Masahiro Yamada , Shuah Khan , Krzysztof Kozlowski , Masami Hiramatsu , Brendan Higgins , Herbert Xu , Ard Biesheuvel , Andy Shevchenko , David Gow , Mark Rutland , Linux Kernel Mailing List , Android Kernel Team 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 Fri, Mar 20, 2020 at 4:19 AM Jason Baron wrote: > > > > On 3/19/20 11:28 AM, Orson Zhai wrote: > > Hi Jason, > > > > On Wed, Mar 18, 2020 at 05:18:43PM -0400, Jason Baron wrote: > >> > >> > >> On 3/18/20 3:03 PM, Orson Zhai wrote: > >>> There is the requirement from new Android that kernel image (GKI) and > >>> kernel modules are supposed to be built at differnet places. Some people > >>> want to enable dynamic debug for kernel modules only but not for kernel > >>> image itself with the consideration of binary size increased or more > >>> memory being used. > >>> > >>> By this patch, dynamic debug is divided into core part (the defination of > >>> functions) and macro replacement part. We can only have the core part to > >>> be built-in and do not have to activate the debug output from kenrel image. > >>> > >>> Signed-off-by: Orson Zhai > >> > >> Hi Orson, > >> > >> I think this is a nice feature. Is the idea then that driver can do > >> something like: > >> > >> #if defined(CONFIG_DRIVER_FOO_DEBUG) > >> #define driver_foo_debug(fmt, ...) \ > >> dynamic_pr_debug(fmt, ##__VA_ARGS__) > >> #else > >> no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) > >> #enif > >> > >> And then the Kconfig: > >> > >> config DYNAMIC_DRIVER_FOO_DEBUG > >> bool "Enable dynamic driver foo printk() support" > >> select DYNAMIC_DEBUG_CORE > >> > > I highly appreciate you for giving this good example to us. > > To be honest I did not really think of this kind of usage. :) > > But it makes much sense. I think dynamic debug might be a little > > bit high for requirement of memory. Every line of pr_debug will be > > added with a static data structure and malloc with an item in link table. > > It might be sensitive especially in embeded system. > > So this example shows how to avoid to turn on dynamci debug for whole > > system but part of it when being needed. > > > >> > >> Or did you have something else in mind? Do you have an example > >> code for the drivers that you mention? > > > > My motivation comes from new Andorid GKI release flow. Android kernel team will > > be in charge of GKI release. And SoC vendors will build their device driver as > > kernel modules which are diffrent from each vendor. End-users will get their phones > > installed with GKI plus some modules all together. > > > > So at Google side, they can only set DYNAMIC_DEBUG_CORE in their defconfig to build > > out GKI without worrying about the kernel image size increased too much. Actually > > GKI is relatively stable as a common binary and there is no strong reason to do > > dynamic debugging to it. > > > > And at vendor side, they will use a local defconfig which is same with Google one but add > > CONFIG_DYNAMIC_DEBUG to build their kenrel modules. As DYNAMIC_DEBUG enables only a > > set of macro expansion, so it has no impact to kernel ABI or the modversion. > > All modules will be compatible with GKI and with dynamic debug enabled. > > > > Then the result will be that Google has his clean GKI and vendors have their dynamic-debug-powered modules. > > > > > static int __init dynamic_debug_init(void) > { > struct _ddebug *iter, *iter_start; > const char *modname = NULL; > char *cmdline; > int ret = 0; > int n = 0, entries = 0, modct = 0; > int verbose_bytes = 0; > > if (__start___verbose == __stop___verbose) { > pr_warn("_ddebug table is empty in a CONFIG_DYNAMIC_DEBUG build\n"); > return 1; Oh, I forgot this. If return error here, "ddebug_init_success = 1;" will be never executed and there will be no debugfs or /proc operation interface for user. > } > > ... > > I wonder if we should just remove it now. I think we could keep it by adding "... && IS_ENABLED(CONFIG_DYNAMIC_DEBUG)" into the condition. Then do the comparison again to __start_verbose and __stop_verbose. If no entries we set ddebug_init_success = 1 and return immediately. I will make patch V2 if you agree with this. Best, -Orson > > Thanks, > > -Jason >