Re: [PATCH 2.6-git] SPI core refresh

[Vitaly Wool <vwool@ru.mvista.com>]

David Brownell wrote:

>>Please remember that using threads is just a default option which may be 
>>even turned off at the kernel configuration stage.
>>    
>>
>
>People keep saying "make it a library" in such cases, and that's the
>kind of layering I've come to think is more appropriate.  So that
>bitbang code needs some reshaping.  As a library, not driver or core.
>  
>
Well, effectively this is the way we do it now... Of course one can 
establish drivers/spi/lib subdir... :)

>>Exposing SPI message structure doesn't look good to me also because 
>>you're making it a part of the interface (and thus unlikely to change).
>>    
>>
>
>The interface will be the interface, sure.  Whatever it is.
>And will accordingly be unlikely to change.  We know that
>from every other API in Linux and elsewhere; nothing new.
>
>Was there some specific issue you forgot to raise here?
>  
>
Well, I've had an experience working with full duplex SPI controller. 
I'm afraid that if you're gonna support it some time in the future, 
you'll have to rework the  message interface, won't you?

>>We're hiding spi_msg internals what allows us to be more flexible in 
>>implementation (for instance, implement our own allocation technique for 
>>spi_msg (more lightweight as the size is always the same).
>>    
>>
>
>What you're doing is requiring a standard dynamic allocation model for
>your "spi_msg" objects ... one per transfer even, much heavier weight than
>the "one per transfer group" model of current "spi_message".  (And much
>heavier than stack based allocation too.)
>  
>
We can allocate a pool of messages at the very init stage and use our 
own technique to grab the next one from the pool in spimsg_alloc.
So we're not requiring _standard_ dynamic allocation model.

Vitaly