Roland Mainz wrote:
> Mahesh Siddheshwar wrote:
>
>> Roland Mainz wrote:
>>
>>> Does it make sense to have a |xu_flags| field here for future
>>> enhancments ?
>>>
>> If future enhancements are needed to extend xuio_t, a new xuio_type
>> can be defined and extended that way. For extensions not specific
>> to xuio, there also exists uio_extflg in the uio_t. Without a particular
>> purpose an additional flag seems unnecessary for zero-copy right now.
>>
>
> Right now... yes. But Unix has a little (IMO) ugly tradition of not
> adding such flag fields and instead swamping the headers with many many
> variations of one interface over time which could be avoided by use
> having a flags field as argument (that's a generic issue).
>
[snip]
>>>> b. Requesting zero-copy buffers
>>>>
>>>> #define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \
>>>> fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct)
>>>>
>>>> int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *,
>>>> caller_context_t *)
>>> AFAIK the prototype should have a flags field to allow future
>>> changes/extenstions without adding another VOP_*-hook ...
>>>
>> Roland, if the extensions/changes are for the purpose of
>> copy reduction/buffer sharing, we don't need to add
>> additional VOP_* routines. The current xuio_t extension is
>> defined just for that.
>>
>
> Erm... the idea of having a flags field in |fop_reqzcbuf()| was to allow
> slight modifications in behaviour - for example in the future there
> could be flags which describe where (in a NUMA system) the buffer memory
> resides (e.g. near the calling thread, near a point which is optimal for
> all consumers, or near the hardware which fills the buffer etc.),
> whether it should be in the L2 cache or not etc. etc.
>
Roland, I agree with Nico on the drawbacks of adding undefined flags for
future use.
You make two suggestions:
1) addition of a flag to xuio_t for future use
2) addition of a flag to VOP_REQZCBUF() for future use.
It's the project team's opinion that these flags are not needed for
this spec, for the following reasons:
For 1) the existence of uio_extflg in uio_t and the possibility of
extending xuio_t through additional xuio_type's, make an
additional 'xu_flags' flag an overhead that can be avoided.
For 2) we don't have a specific purpose for the flag right now.
If there is a need for additional flags or arguments in future,
the VOP routine can be easily extended. As has been done in
the recent past with several extensions for existing VOP routines
(PSARC 2007/244, 2007/218, 2007/227, 2009/387).
The existence of strong type checking for vnode/vfs operations
through PSARC 2007/124 make it easier to catch an interface mismatch.
Thanks,
Mahesh
