lkml.org 
[lkml]   [2005]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-12-11 13:42    [W:0.082 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site