[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181108081345.GG20032@gmail.com>
Date: Thu, 8 Nov 2018 09:13:45 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Peter Zijlstra <peterz@...radead.org>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
John Stultz <john.stultz@...aro.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Frederic Weisbecker <frederic@...nel.org>,
Jonathan Corbet <corbet@....net>,
Andy Lutomirski <luto@...nel.org>,
Marc Zyngier <marc.zyngier@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Will Deacon <will.deacon@....com>,
Mark Brown <broonie@...nel.org>,
Dan Williams <dan.j.williams@...el.com>
Subject: Re: [patch 2/2] Documentation/process: Add tip tree handbook
* Thomas Gleixner <tglx@...utronix.de> wrote:
> +Namespaces
> +^^^^^^^^^^
> +
> +To improve readability and to allow easy grepping for information the usage
> +of consistent namespaces is important. The namespace should be used as a
> +prefix for globally visible (inline) functions and variables. A simple rule
> +for chosing a namespace prefix is to combine the subsystem and the
> +component name, e.g. 'x86_comp\_', 'sched\_', 'irq\_', 'mutex\_', etc. For
> +static functions and variables the namespace prefix can be omitted.
> +
> +Also be careful when using vendor names in namespaces. There is no value of
> +having 'xxx_vendor\_' or 'vendor_xxx_` as prefix for all static functions
> +of a vendor specific file as it is already clear that the code is vendor
> +specific. Aside of that vendor names should only be used when it is really
> +vendor specific functionality.
> +
> +As always apply common sense and aim for consistency and readability.
I'd also suggest adding:
> +This also includes static file scope functions that are immediately put into
> +globally visible driver templates - it's useful for those symbols to carry a
> +good prefix as well, for backtrace readability.
> +
> +Truly local functions, only called by other local functions, can have
> +shorter descriptive names - our primary concern is greppability and
> +backtrace readability.
Beyond the driver-template aspect also note the backtrace readability
argument I added: good namespaces are not just about greppability.
Thanks,
Ingo
Powered by blists - more mailing lists