Messages in this thread | | | Date | Wed, 31 Jan 2001 23:43:51 +0000 | From | "Stephen C. Tweedie" <> | Subject | Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait/notify + callback chains |
| |
Hi,
On Tue, Jan 30, 2001 at 10:15:02AM +0530, bsuparna@in.ibm.com wrote: > > Comments, suggestions, advise, feedback solicited !
My first comment is that this looks very heavyweight indeed. Isn't it just over-engineered?
We _do_ need the ability to stack completion events, but as far as the kiobuf work goes, my current thoughts are to do that by stacking lightweight "clone" kiobufs.
The idea is that completion needs to pass upwards (a) bytes-transferred, and (b) errno, to satisfy the caller: everything else, including any private data, can be hooked by the caller off the kiobuf private data (or in fact the caller's private data can embed the clone kiobuf).
A clone kiobuf is a simple header, nothing more, nothing less: it shares the same page vector as its parent kiobuf. It has private length/offset fields, so (for example) a LVM driver can carve the parent kiobuf into multiple non-overlapping children, all sharing the same page list but each one actually referencing only a small region of the whole.
That ought to clean up a great deal of the problems of passing kiobufs through soft raid, LVM or loop drivers.
I am tempted to add fields to allow the children of a kiobuf to be tracked and identified, but I'm really not sure it's necessary so I'll hold off for now. We already have the "io-count" field which enumerates sub-ios, so we can define each child to count as one such sub-io; and adding a parent kiobuf reference to each kiobuf makes a lot of sense if we want to make it easy to pass callbacks up the stack. More than that seems unnecessary for now.
--Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |