Messages in this thread | | | Date | Sun, 11 Dec 2005 15:36:46 +0300 | From | Vitaly Wool <> | Subject | Re: [PATCH 2.6-git] SPI core refresh |
| |
David Brownell wrote:
>>Yeah thus we don't have an ability to allocate SPI messages on stack as >>you do, that's what votes for your approach. Yours is thus a bit faster, >>though I suspect that this method is a possible *danger* for really >>high-speed devices with data bursts on the SPI bus like WiFi adapters: >>stack's gonna suffer from large amounts of data allocated. >> >> > >No, you're still thinking about a purely synchronous programming model; >which we had agreed ages ago was not required. > > Ah yes. But wait... I've got an important question here. For instance, let's take your MTD driver. You're allocating a message structure on stack and passing it then down to spi->master->transfer function. The benefit you're talking about is that you don't have to use heavyweight memory allocation. But... the transfer is basically async so spi->master->transfer will need to copy your message structure to its own-allocated structure so some memory copying will occur as this might be an async transfer (and therefore the stack-allocated message may be freed at some point when it's yet used!) So your model implies concealed double message allocation/copying, doesn't it? And if I'm wrong, can you please explain me this?
Vitaly - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |