[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18209.29891.911465.715995@cargo.ozlabs.ibm.com>
Date: Fri, 26 Oct 2007 15:01:55 +1000
From: Paul Mackerras <paulus@...ba.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Rusty Russell <rusty@...tcorp.com.au>,
Boaz Harrosh <bharrosh@...asas.com>,
Jens Axboe <jens.axboe@...cle.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Linux Kernel Development <linux-kernel@...r.kernel.org>,
mingo@...e.hu
Subject: Re: [PATCH 09/10] Change table chaining layout
Linus Torvalds writes:
> Nobody should *ever* walk the list to find the length. Does anybody really
> do that? Yes, we pass the thing down, but do people *need* it?
Yes, I need it for devices that use the macintosh DBDMA
(descriptor-based DMA) hardware. The DBDMA hardware reads an array of
descriptors from system RAM, so I need to allocate an array and fill
it in with DBDMA command blocks (and then dma-map it and point the
device at it).
> [ Side note: some of the users of that length currently would seem to be
> buggy in the presense of continuation entries, and seem to assume that
> the "list" is just a contiguous array. In fatc, that's almost the only
> valid use for the "count" thing, since any other use _has_ to walk it
> entry by entry anyway, no? ]
Maybe the drivers for devices that use DBDMA are now buggy. Certainly
filling in the array of DBDMA command blocks involves walking the
list, but it would extremely useful to know how much to allocate
before we start filling them in. So we at least need an upper bound
on the number of "real" entries, even if we don't have the exact
number.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists