linux-kernel - Re: [PATCH] xfs: #define out unused parameters of xfs_bmap_add_free and xfs_btree_read

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: <480E1FAE.20509@sandeen.net>
Date:	Tue, 22 Apr 2008 12:26:06 -0500
From:	Eric Sandeen <sandeen@...deen.net>
To:	Adrian Bunk <bunk@...sta.de>
CC:	Denys Vlasenko <vda.linux@...glemail.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] xfs: #define out unused parameters of	xfs_bmap_add_free
 and xfs_btree_read_bufl

Adrian Bunk wrote:
> On Tue, Apr 22, 2008 at 06:17:03PM +0200, Denys Vlasenko wrote:


>>> Elimination of completely unused parameters makes sense, but IMHO using 
>>> such #define hacks for minuscule code size and stack usage advantages is 
>>> not worth it.
>> In busybox this trick is used extensively.
> 
> Busybox does not have more than one million lines changed in
> one release.
> 
> In the Linux kernel maintainability is much more important than in 
> smaller projects.
> 
>> I don't know how to eliminate these unused parameters with less
>> intervention, but I also don't want to leave it unfixed.
>>
>> I want to eventually reach the state with no warnings
>> about unused parameters.
> 
> The standard kernel pattern in using empty static inline functions (that 
> allow type checking).
> 
> And I'm not sure whether the number of functions you'd have to change 
> for reaching your goal has four, five or six digits.

It would be a huge undertaking.

Just building xfs w/ the warning in place exposes tons of unused
parameter warnings from outside xfs as well.

But, if it was deemed important enough, you could go annotate them as
unused, I suppose, and hack away at it...  Does marking as unused just
shut up the warning or does it let gcc do further optimizations?

-Eric
--
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/