On 05/03/13 15:16, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 05, 2013 at 08:11:19AM +0000, Jan Beulich wrote: >>>>> On 04.03.13 at 21:44, Konrad Rzeszutek Wilk <konrad.w...@oracle.com> >>>>> wrote: >>> <nods> 'op' sounds good. With a comment saying it can do all of the >>> BLKIF_OPS_.. >>> except the BLKIF_OP_INDIRECT one. Thought one could in theory chain >>> it that way for fun. >> >> In fact I'd like to exclude chaining as well as BLKIF_OP_DISCARD here. >> The former should - if useful for anything - be controlled by a >> separate feature flag, and the latter is plain pointless to indirect. >> And I reckon the same would apply to BLKIF_OP_FLUSH_DISKCACHE >> and BLKIF_OP_RESERVED_1 - i.e. it might be better to state that >> indirection is only permitted for normal I/O (read/write) ops. > > <nods> That makes sense. And also of course the new BLKIF_OP should > be documented in the Xen tree as well.
The only ops that can be done indirectly are _READ, _WRITE and _BARRIER/_FLUSH. From the implementation in blkfront it seems like _FLUSH/_BARRIER requests can indeed contain segments, but I haven't been able to spot any _FLUSH op with segments on it. Can you confirm FLUSH requests never contain bios? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/