xfs
[Top] [All Lists]

Re: [PATCH] xfs: remove unused locking flags

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: [PATCH] xfs: remove unused locking flags
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 10 Jul 2006 17:51:00 +0100
Cc: Alexey Dobriyan <adobriyan@xxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
In-reply-to: <20060710081711.A1670244@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <20060708215324.GA7522@xxxxxxxxxxxxxxxxxxxxxx> <20060709105454.D1640104@xxxxxxxxxxxxxxxxxxxxxxxx> <20060709125643.GA28769@xxxxxxxxxxxxx> <20060710081711.A1670244@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Mon, Jul 10, 2006 at 08:17:11AM +1000, Nathan Scott wrote:
> On Sun, Jul 09, 2006 at 01:56:43PM +0100, Christoph Hellwig wrote:
> > On Sun, Jul 09, 2006 at 10:54:54AM +1000, Nathan Scott wrote:
> > I don't think theres a valid reason to keep such dead code around.  If
> 
> Its not dead code.  I will and have been happily removing dead
> code.

It's 100% dead code in mainline.  Please don't push in new code that doesn't
do anything.

> > There seem to be some rather odd things creeping in lately.
> 
> Er, such as?  And why not point these things out at the time,
> when people are working on it and committing the changes (and
> sending commit mail to xfs@oss), instead of this odd vague
> reference now?

Sorry about the odd reference.  I don't really have time to look up
the changes for each TAKE message in cvsweb nevermind especially odd
changes seem to not come with TAKE messages sometimes.   So I have to
look at the changes between two linus releases to see changes.

Anyway, the odd changes from 2.6.17 to 2.6.18-rc are:

 - replacing PFLAGS_* with even more obsfucation
 - the big renaming of the vnode/vfs thingies.  I take this as an official
   go-ahead that this cruft isn't for irix-compatibility anymore and remove
   it.  I have a nice patch pending that reduces xfs size big time with
   this (unfortunatly needs a nasty rebase now)
 - the VN_TRUNC looks interesting.  I wish we had a public discussion about
   this and could see whether or not to handle it at the VFS level
 - adding a new inherit_nodfrg flag that's not actually used anywhere
 - addding a VFS_UMOUNT flag that isn't actually used anywhere and shouldn't
   exist with Linux's unmount handling


<Prev in Thread] Current Thread [Next in Thread>