"A month of sundays ago ptb wrote:"
> "A month of sundays ago Thunder from the hill wrote:"
> > > And for the O_DIRECT flag we seem to do alloc_kiovec(1, &f->f_iobuf).
> >
> > Perhaps we should go biovec here?
State of play:
1) I abandoned doing the dentry_open with O_DIRECT flags bit
from within the driver, because every external access then errored
with EINVAL without getting to my driver functions.
2) I then just tried opening the device normally from userspace
but with O_DIRECT set. This is harder than it should have been - I had
to set nearly everything in features.h on before I got the desired
compilation (was it _XOPEN_SOURCE that did it? I forget), and surprise,
surprise, I get exactly the same effects as in (1). Every access
errors with EINVAL and my driver code never gets called. An open
with code compiled without O_DIRECT works fine, as usual.
I put a little debugging in the driver open call. With O_DIRECT
in the userspace open:
#881[12]: _open have O_DIRECT iobuf 0xcf935000 for part 0
#883[12]: _open have i_mapping 0xcce7f874 for part 0
#885[12]: _open have a_ops 0xc029ef40 for part 0
#889[12]: _open have direct_IO 0xc013edc0 for part 0
(I presume the latter is generic_file_direct_IO - it's not in my
map, but it's static so shouldn't be).
and without:
#881[14]: _open have ~O_DIRECT iobuf 0x0 for part 0
#883[14]: _open have i_mapping 0xcce7f874 for part 0
#885[14]: _open have a_ops 0xc029ef40 for part 0
#889[14]: _open have direct_IO 0xc013edc0 for part 0
So it looks as though some driver cooperation is required in
order for direct_IO/O_DIRECT to work.
What? Anyone know?
Peter
-
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/
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:23 EST