Re: 2.4.19pre5aa1 and splitted vm-33

[Andrea Arcangeli <andrea@suse.de>]

On Sun, Mar 31, 2002 at 07:10:59PM +0100, Christoph Hellwig wrote:
> On Sun, Mar 31, 2002 at 04:48:15PM +0200, Andrea Arcangeli wrote:
> > Only in 2.4.19pre5aa1: 00_o_direct-open-check-1
> > 
> > 	Move the check for O_DIRECT support into the open(2) syscall. Make
> > 	sense, also the xine folks asked for that feature to cleanup
> > 	some userspace. Patch from Chuck Lever.
> 
> This breaks XFS O_DIRECT handling, which is not implemented through ->direct_IO.

Hmm that's a problem. BTW, is there any valid reason xfs isn't
implementing O_DIRECT via the direct_IO address space operation like the
other filesystems ext2/reiserfs/nfs? (of course I'm talking long term, I
don't pretend to change that in one day, for the short term we should
still allow xfs to use its own internal methods of doing O_DIRECT)

Fixing that should be a one liner setting a_ops->direct_IO to
ERR_PTR(-1L) within xfs. Comments?

> For the open case putting the check into generic_file_open sounds good to me,

One problem with generic_file_open is that we'd need to rely on all
lowlevel open callbacks to do the check properly if they don't support
O_DIRECT and we'd need to duplicate code, only a few fs uses
generic_file_open.  Lefting it in the vfs looked cleaner, it reduces the
check to a few liner patch.

The lowlevel callback can always drop the kiovec during its own ->open
if they don't need it, even if they uses direct_IO, like nfs.

> but I have no idea on how to handle the fcntl case - which btw already allocates
> kiobufs even if XFS doesn't need them..

Chuck's patch is handling fcntl as well, do you see any problem there?
(modulo the fact the kiovec is pre-allocated even if not necessary, like
in open(2)?)

Andrea