linux-kernel - Re: Clarifying confusion of our variable placement rules caused by cleanup.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aW01ludvLz9xNzkd@stanley.mountain>
Date: Sun, 18 Jan 2026 22:33:42 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Andy Shevchenko <andriy.shevchenko@...el.com>,
	ksummit@...ts.linux.dev, Dan Williams <dan.j.williams@...el.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Clarifying confusion of our variable placement rules caused by
 cleanup.h

On Sun, Jan 18, 2026 at 02:17:30PM -0500, James Bottomley wrote:
> > > Duplicate header are trivially caught by tooling.
> > > 
> > > But such rules aren't useful either -- I've seen that Python IDEs
> > > hide import list by default (and probably manage it) because it is
> > > not "real" code.
> > > 
> > > Rules for initializers can be harmful because ordering affects code
> > > generation.
> > 
> > I agree. I still prefer the upside-down x-mas tree approach for
> > declaring variables, but obviously if they also get initialized, then
> > that trumps aesthetic reasoning.
> 
> How is any of this relevant to a style document?  You're quibbling over
> individual maintainer foibles which, while they may be deeply held to
> you (and obviously are relevant to contributors to your subsystems
> because they need to know your foibles), can't be part of our universal
> advice because not all maintainers agree (not even on the direction of
> the Christmas Tree).
> 

The direction of the Christmas Tree is always upside down.  That's a
standard in networking and a bunch of other subsystems.  Otherwise
people don't care.  I've seen people who write code in Right Side Up
Christmas Tree style but they don't reject code which is in a different
order.

If you're working across the entire kernel like I do then it's safest
to assume Upside Down Christmas Tree is the rule.

regards,
dan carpenter