In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>
[...]
> The question which I was looking into was whether we could have a generic
> interface for enabling filesystem specific formatting/modification/
> post-processing of data read in via an asynchonous i/o mechanism (and
> similarly some post-processing action on async write completion), without
> each filesystem implementation having to explicitly do this on their
> own (say e.g. using just block_read_full_page, and then having its own
> readpagecompletion routine to the non-standard work, or in the case of
> a stackable filesystem, using the underlying readpage to do most of the
> work except for the post-processing needed).
> We can think of it as an interface for re-entry into the filesystem
> logic after page i/o is done.
> So, it'd be nice if this were not restricted for use by stacked
> filesystems and even the lowest level filesystem could use this
> interface.
Yes it's possible, with changes to the VFS of course. You could add our
wrapfs {encode,decode}_{block,filename} functions optional parts of some OPs
vectors. This won't be too difficult and is code that's been well tested in
our stacking templates.
We also have code to support size-changing file systems (for compression
etc.) but that's a lot more additional code that needs testing.
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
