linux-kernel - Re: [RFC 0/2] vfs / btrfs: add support for ustat()

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: <20140716191319.GN10393@wotan.suse.de>
Date:	Wed, 16 Jul 2014 21:13:19 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	viro@...iv.linux.org.uk, clm@...com, jbacik@...com,
	linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, jeffm@...e.com, fdmanana@...e.com
Subject: Re: [RFC 0/2] vfs / btrfs: add support for ustat()

On Tue, Jul 15, 2014 at 10:29:19PM -0700, Christoph Hellwig wrote:
> Isn't this the problem again the btrfs uses different assignments for
> st_dev than s_dev?  I don't even want to think about a mess like this
> before that is fixed.

As much as I'd like to see that happen based on discussions so far its unclear
if this is going to be possible unless strong commitment is reached... so what
this tried to do was to take the other way around the problem, by slowly
shifting out junk. Although I'm frankly new to this -- I think this approach might
be more feasible over time. As I see it this is an extension to Al's original
commit 0ee5dc676 but more in line with how they are really are used and exposes
more information to the VFS. As it stands now other filesystems can pop up and
do similar things, this at least extends the original API to fit the use case a
bit more closely to how its used and allows more room to grow.

  Luis

Content of type "application/pgp-signature" skipped