linux-kernel - Re: linux-next: build warninga in Linus' tree

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]

Date:	Wed, 1 Jun 2011 10:16:48 -0500
From:	Mitch Harder <mitch.harder@...ayonlinux.org>
To:	dave@...os.cz, Stephen Rothwell <sfr@...b.auug.org.au>,
	Chris Mason <chris.mason@...cle.com>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-btrfs@...r.kernel.org
Subject: Re: linux-next: build warninga in Linus' tree

On Tue, May 31, 2011 at 12:57 PM, David Sterba <dave@...os.cz> wrote:
> Hi,
>
> On Mon, May 30, 2011 at 11:36:53AM +1000, Stephen Rothwell wrote:
>> After merging the Linus' tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced these warnings:
>>
>> fs/btrfs/sysfs.c:76:26: warning: 'btrfs_root_attrs' defined but not used
>> fs/btrfs/sysfs.c:97:26: warning: 'btrfs_super_attrs' defined but not used
>> fs/btrfs/sysfs.c:153:13: warning: 'btrfs_super_release' defined but not used
>> fs/btrfs/sysfs.c:160:13: warning: 'btrfs_root_release' defined but not used
>>
>> I have started using gcc v4.5.2 (instead of v4.4.4) if that makes a
>> difference.
>
> the warning probably started to show up after one of my cleanup patches,
> removing unused functions (f2a97a9dbd86eb1ef956bdf20e05c507b32beb96).
> The sysfs interface is not being used right now, but there's a unmerged
> patchset which adds the interesting bits like info about available btrfs
> filesystems and devices. I don't know what are the intentions regarding
> sysfs.
>
>
> david

I've been playing around with resurrecting the basic sysfs
capabilities that had been previously incorporated into btrfs.

As it stands right now, it was relatively easy to re-implement sysfs
as it was originally.  However, that implementation of sysfs wasn't
populated with much information (only total_blocks, blocks_used, and
blocksize).

I also had to reverse a small portion of code that was in the last clean-up.

If a CONFIG_BTRFS_DEBUG type configuration flag is ever introduced, it
would be interesting to resurrect btrfs' sysfs capabilities.
--
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/