On 09/09/09 17:08, Garrett D'Amore wrote:
> I've not had time to go over all this yet, but do we really believe this
> kind of change is fast track appropriate? I have a feeling that this is
> a significant enough core change with implications for a variety of
> project teams, that maybe this one ought to be a full case. I'd be a
> bit uncomfortable allowing this one to just time out with a single +1,
> which is the normal rule for fast tracks.
>
> Am I alone in this particular concern?
>
> Are there any implications for unbundled 3rd party filesystems?
>
> - Garrett
>
Garrett,
Perhaps this will help.
As the sponsor, I asked myself the same question. This seemed similar
in scope to another fast-track: PSARC/2007/315 (Extensible Attribute
Interfaces). One could argue that this proposal is smaller in scope
and impact since there are no user level interfaces involved.
Here's what I considered during my review of the project (which might
help make the proposal a bit more digestible):
- The proposal extends the uio_t structure in a way that includes
(and cleans up) the existing uioa_t (asynchronous uio) structure
and adds a "zero copy" feature. With all due respect to the original
implementors of uioa_t, this proposal seemed like a cleaner, more
flexible solution to extending the functionality of the uio_t structure.
This is roughly equivalent to the way that the vattr_t structure was
extended with the xvattr_t structure in PSARC/2007/315.
- This does not change the way that the existing VOP_READ/VOP_WRITE
implementations work the same way that the addition of xvattr_t
didn't change the way existing VOP_GETATTR/VOP_SETATTR implementations.
Only those file systems that explicitly choose to participate
in the extensions need to change their VOP_READ and VOP_WRITE
implementations to handle the xuio_t structure. The current use
of the uio_t structure will still work.
- Also, only those file systems that explicitly choose to participate
in the zero-copy feature need to implement VOP_REQZCBUF and
VOP_RETZCBUF. For those file systems that do not implement these
interfaces, they will automatically default to fs_nosys() without
any effort by the file system implementor thanks to the vnode/vfs
operation registration mechanism (introduced in PSARC/2001/679).
Just to be clear, unbundled (Sun and 3rd party) file systems won't
notice any difference.
Rich
