linux-kernel - Re: Btrfs for mainline

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:	Sat, 3 Jan 2009 14:12:59 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Chris Mason <chris.mason@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>
Subject: Re: Btrfs for mainline

On Sat, Jan 03, 2009 at 02:50:34PM -0500, Christoph Hellwig wrote:
> On Sat, Jan 03, 2009 at 12:17:06PM -0700, Matthew Wilcox wrote:
> > It's no worse than XFS (which still has its own implementation of
> > 'synchronisation variables',
> 
> Which are a trivial wrapper around wait queues.  I have patches to kill
> them, but I'm not entirely sure it's worth it

I'm not sure it's worth it either.

> > a (very thin) wrapper around mutexes,
> 
> nope.

It's down to:

typedef struct mutex mutex_t;

but it's still there.

> > a
> > (thin) wrapper around rwsems,
> 
> Which are needed so we can have asserts about the lock state, which
> generic rwsems still don't have.  At some pointer Peter looked into
> it, and once we have that we can kill the wrapper.

Good to know.  Rather like btrfs's wrappers around mutexes then ...

> > > - compat.h needs to go
> > 
> > Later.  It's still there for XFS.
> 
> ?

XFS still has 'fs/xfs/linux-2.6'.  It's a little bigger than compat.h,
for sure, and doesn't contain code for supporting different Linux
versions, sure.  But it's still a compat layer.

> > > - there should be manpages for all the ioctls and other interfaces.
> > 
> > I wonder if Michael Kerrisk has time to help with that.  Cc'd.
> 
> Actually a lot of the ioctl API don't just need documentation but
> a complete redo.  That's true at least for the physical device
> management and subvolume / snaphot ones.

That's a more important critique than Andi's.  Let's take care of that.

> From painfull experience with a lot of things, including a filesystem
> you keep on mentioning it's clear that once stuff is upstream there
> is very little to no incentive to fix these things up.

I don't think that's as true of btrfs as it was of XFS -- for example,
Chris has no incentive to keep compatibility with IRIX, or continue to
support CXFS.  I don't think 'getting included in kernel' is Chris'
goal, so much as it is a step towards making btrfs better.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/