Ion Badulescu wrote:
>
> On Mon, 11 Sep 2000, Andi Kleen wrote:
>
> > > Passing an update_fpos boolean would be so much cleaner.
> >
> > An update_fpos boolean only would require that pread/pwrite create their own
> > file structure to pass in the user offset.
>
> Ok, true, I didn't think of that. But then passing the boolean in
> *addition* to the pointer to fpos would allow the stackable filesystem to
> detect the pread() case cleanly and thus to handle it correctly without
> hackery like the one I described.
Your solution isn't any more of a hack than having an extra pointer to
implement the pread/write functionality. Such hacks desperately
require a clairfying comment in the code, and instead of bleating
about it here I suppose I should be preparing a patch.
I got off on this tangent when I was looking at another small wart,
the place where we ignore file->f_pos in favor of
file->f_dentry->inode->i_size in the case that the file is flagged
append-only. This functionality has to be emulated when you override
file_operations::write. I thought it just might be possibly to pull
both these irregularities out to the top level (sys_read/sys_write).
Hence the stupid question: what, if anything, relies on this
arrangement?
I'll continue down this path just a little further, out of interest.
If you try define pread/pwrite in terms of read/write, i.e.:
save pos
set pos
call read/write
restore pos
/* bad idea */
you get into a big mess trying to make it concurrent and efficient at
the same time. The only acceptable mechanism for pread/pwrite is one
that prevents all changes to file->f_pos. But you can easily
implement read/write in terms of pread/pwrite:
read/write (file, len):
file(pos) += pread/pwrite (file, file(pos), len)
(in pidgin C)
Error handling is slightly messed up in this case because the error
codes are overloaded onto the length returned by pread/pwrite.
However the approach is still pretty clean because you end up with
just one path for the file position result instead of two. This seems
desireable and achievable - but not if it derails somebody's work in
some fundamental way.
> The main problem with the stackable fs is that is has two halves, one
> filesystem-like and one VFS-like. The VFS half must know how the
> filesystem half was called, so it can call the underlying filesystem's
> read() method in the same way.
Why does it have to call the underlying filesystem in the same way?
Isn't it enough just to have the correct results at the top level?
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
