I'd never dipute that. It was just an answers to Stephen's "a kiobuf is
already smaller".
> > enum kio_flags {
> > KIO_LOANED, /* the calling subsystem wants this buf back */
> > KIO_GIFTED, /* thanks for the buffer, man! */
> > KIO_COW /* copy on write (XXX: not yet) */
> > };
>
> This is a Really Bad Idea. Having semantics depend on a subtle flag
> determined by a caller is a sure way to
The semantics aren't different for the using subsystem. LOANED vs GIFTED
is an issue for the free function, COW will probably be a page-level mm
thing - though I haven't thought a lot about it yet an am not sure wether
it actually makes sense.
>
> >
> >
> > struct kio {
> > struct kiovec * kio_data; /* our kiovecs */
> > int kio_ndata; /* # of kiovecs */
> > int kio_flags; /* loaned or giftet? */
> > void * kio_priv; /* caller private data */
> > wait_queue_head_t kio_wait; /* wait queue */
> > };
> >
> > makes it a lot simpler for the subsytems to integrate.
>
> Keep in mind that using distant memory allocations for kio_data will incur
> additional cache misses.
It could also be a [0] array at the end, allowing for a single allocation,
but that looks more like a implementation detail then a design problem to me.
> The atomic count is probably going to be widely
> used; I see it being applicable to the network stack, block io layers and
> others.
Hmm. Currently it is used only for the multiple buffer_head's per iobuf
cruft, and I don't see why multiple outstanding IOs should be noted in a
kiobuf.
> Also, how is information about io completion status passed back
> to the caller?
Yes, there needs to be an kio_errno field - though I wanted to get rid of
it I had to readd in in later versions of my design.
Christoph
-- Of course it doesn't work. We've performed a software upgrade. - 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/