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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 0694FC2D0DB for ; Thu, 23 Jan 2020 18:16:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DB8F42077C for ; Thu, 23 Jan 2020 18:16:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728988AbgAWSQ6 convert rfc822-to-8bit (ORCPT ); Thu, 23 Jan 2020 13:16:58 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:51954 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727278AbgAWSQ6 (ORCPT ); Thu, 23 Jan 2020 13:16:58 -0500 Received: from marcel-macbook.fritz.box (p4FEFC5A7.dip0.t-ipconnect.de [79.239.197.167]) by mail.holtmann.org (Postfix) with ESMTPSA id 43A7ECED02; Thu, 23 Jan 2020 19:26:16 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: [Bluez PATCH] doc: Add definition for Set Kernel Debug Level From: Marcel Holtmann In-Reply-To: Date: Thu, 23 Jan 2020 19:16:56 +0100 Cc: Johan Hedberg , Alain Michaud , BlueZ Content-Transfer-Encoding: 8BIT Message-Id: References: <20200120202708.111383-1-alainm@chromium.org> <6E55772A-01D5-4616-B3DB-CC22B935C855@holtmann.org> To: Alain Michaud X-Mailer: Apple Mail (2.3608.40.2.2.4) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Alain, > From a high level, this looks good for me although I agree, this is an > order of magnitude bigger in terms of scope. Can you suggest perhaps > an interactive way to deliver this over a period of time, perhaps > prioritizing the BT_DEBUG kernel messages first? :) I am always in favor of increasing the ability to debug things, but we need to do this in a clean fashion and not some short term hacks (since they will come back and haunt us). I like to get some review on my idea first. What we could do is work on the BT_DBG etc infrastructure to allow switching when dynamic_debug is not available. Then you would use some debugfs toggle in /sys/kernel/debug/bluetooth since that is no stable API for us (and of course the clear understanding that this toggle is temporary). Regards Marcel