Re: dealing with excessive includes

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 18 Oct 2006, Al Viro wrote:
> 
> Actually, after reading that code I suspect that get_fs_excl() in there
> is the wrong thing to do.  Why?  Because the logics is all wrong.
> 
> Look what we do under lock_super().  There are two things: ->remount_fs()
> and ->write_super().  Plus whatever low-level filesystems are using
> lock_super() for.

I think this all boils down to the fact that "lock_super()" really is a 
very old and broken interface. It pretty much harks back to the original 
filesystem code, and yes, every "lock_super()" _should_ probably be 
replaced by a lower-level lock.

I think ext2 was already fixed to use its own spinlocks for bitmap 
accesses, although it looks like somebody re-introduced "lock_super()" 
there for xattr handling.

[ Which in turn is probably just a bug, since nothing else uses it, so 
  having a single lock_user() in all of ext2 is almost certainly totally 
  pointless - there is nothing that it actually _protects_ against. I 
  guess it protects against "sync()", but that's pretty much it. ]

That said, I'd rather do any lock_super() cleanup totally _independently_ 
of a include file cleanup. 

So since it's clearly not performance-critical, how about just making it 
be out-of-line in fs/super.c, and turn the header file into just a 
declaration?

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/