linux-kernel - Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.55.0805072214090.25644@cliff.in.clinika.pl>
Date:	Wed, 7 May 2008 22:25:08 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Jean Delvare <khali@...ux-fr.org>
cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	rtc-linux@...glegroups.com, i2c@...sensors.org,
	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org,
	David Brownell <david-b@...bell.net>
Subject: Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization

Hi Jean,

> > > i2c-foo.c is consistently used for i2c bus driver themselves so far.
> > > It's somewhat confusing to see you name platform code that way. It's
> > > also redundant, given that the file lives in the swarm platform
> > > directory. May I suggest naming this file just
> > > arch/mips/sibyte/swarm/i2c.c? Other architectures (cris, arm) are doing
> > > this already.
> > 
> > Is there any chance CONFIG_I2C_BOARDINFO could become tristate?
> > If yes, it's problematic if you have multiple modules called i2c.ko.
> 
> No, CONFIG_I2C_BOARDINFO is boolean by nature, it will never become
> tristate.

 I can do that and I have considered it while preparing the change.  What
convinced me not to use a name that is already present elsewhere in the
tree is the confusion that it sometimes causes.  For example during a
debugging session GDB only reports the file name and not the leading
pathname (and some people do run GDB over the kernel).  Of course the
actual file can still be chased with some `find' and `grep' scriptery, but
why to create a problem in the first place?

 I consider repeated file names throughout a tree of a single program a 
namespace pollution similar to one with repeated static symbol names.  
While syntactically valid and working, it asks for unnecessary confusion.

 This is my point of view, but I can see others may not necessarily follow
it.  I am fine with changing the name to i2c.c as it is unlikely I will
run GDB over it. ;-)

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/