On Tue, 22 Aug 2000, Linus Torvalds wrote:
> > SOmething similar to the skb's would be preferable - so I can just take
> > write blocks and chain them into the DMA hardware. Incoming data can go
> > into "skb's" as well up to the tty.
>
> No. That is just horrible. What's so wrong with simple flip-buffers that
> they wouldn't work for you? Simple, and you can fill them up as fast as
> you can and then flip. Sure, if nobody reads the buffers fast enough
> you'll have trouble, but that's independent of how you do things. It's a
> basic law of the universe (called the "if nobody is listening, it doesn't
> matter how loudly or slowly you talk" law).
Ok a flip-buffer on receive which I DMA into is of course equivalent to
"skb"'s with a max outstanding count of 1 but without the allocation/free
code. So as long as the consumer eats the data quickly or the data is not
bursty that will work fine (and the other cases are probably to instable
to work with anyway, depending on if for example scheduling latencies are
a concern or not).
It was more on the output side I was thinking something more efficient
could be used than a copy into the write-buffer - but now that I think
about it, if we're to avoid pinning down user-pages, we still need to do
that copy somewhere so skb's wouldn't help there anyway...
Anyway, my main point was that I still hope to being able to DMA directly
into the tty flipbuffer etc. even if serial.c is split up, and I think
Rogier agreed there so all is well.. (ok actually we have our own
"serial.c" anyway but it would be nice to not having to duplicate all that
device-independant code eventually)
-Bjorn
-
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/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:08 EST