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:50:34 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Matthew Wilcox <matthew@....cx>
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 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

> a (very thin) wrapper around mutexes,

nope.

> 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.

and wrappers around kmalloc and kmem_cache.
> 
> > - compat.h needs to go
> 
> Later.  It's still there for XFS.

?

> > - 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.

> > - various checkpath.pl level problems I think (e.g. printk levels) 
> 
> Can be fixed up later.
> 
> > - the printks should all include which file system they refer to
> 
> Ditto.

>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.

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