Re: ->direct_IO API change in current 2.4 BK

[Jeff Garzik <jgarzik@pobox.com>]

On Wed, Jul 09, 2003 at 09:08:53PM +0200, Trond Myklebust wrote:
> >>>>> " " == Jeff Garzik <jgarzik@pobox.com> writes:
> 
>      > s/replacing/adding/
> 
> Revert ;-)
> 
>      > A new ->direct_IO2 hook would be an addition, so you really
>      > want to simply add another feature flag.
> 
> You missed the point. This is *instead* of ->direct_IO2. It's only
> purpose would be to distinguish between the old
> 
>  int (*direct_IO)(int, struct inode *, struct kiobuf *, unsigned long, int);
> 
> 
> and the new
> 
>  int (*direct_IO)(int, struct file *, struct kiobuf *, unsigned long, int);

I respectfully disagree, then.

The 2.5 direct_IO API is already different from 2.4, so, changing
the 2.4 stable API implies creating yet another different version of
the API.

When this situation presented itself earlier, with reiserfs, the
solution was ->read_inode2.  I think that same situation applies here.

Having the stable API change, conditional on a define, is really
nasty and IMO will create maintenance and support headaches down
the line.  I do not recall Linux VFS _ever_ having a hook's definition
conditional.  We should not start now...

We need a 2.4-specific solution for this.  ->direct_IO2 should suffice,
and it follows historical example.

XFS, ocfs, and others need only to test the HAVE_NEW_24_DIRECT_IO
define.

In the core kernel implementation, it is trivial to say "if direct_IO2
is non-NULL, use that, otherwise use direct_IO", without needing to make
any code conditional at all.

	Jeff