[U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Anton Staaf]

On Mon, Aug 29, 2011 at 1:35 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Anton Staaf,
>
> In message <CAF6FioWhhqbVQWWPrusb69S2mpfBtoiazxc8x56bkogJmzXZ3g at mail.gmail.com> you wrote:
>>
>> I would like to know, mainly for my education, why you do not want
>> alloca, but are OK with dynamic array sizing (as in the first solution
>> above).  My understanding is that they pretty much equate to the same
>> thing.  What is it about alloca that is objectionable?
>
> First, I've got bitten by alloca() before, when GCC misbehaved.
> Admitted, that was in some _very_ old version, but such experience
> sticks.

Very fair, I have programming constructs I avoid for the same reason.
*cough* exceptions *cough*

> Second, the behaviour of alloca() depends on a number of non-obvious
> settings and compiler flags, and results are not always obvious.  rom
> the man page:
>
>   Notes on the GNU Version
>       Normally, gcc(1) translates calls to alloca() with inlined
>       code. This is not done when either the -ansi, -std=c89,
>       -std=c99, or the -fno-builtin option is given (and the header
>       <alloca.h> is not included). But beware! By default the glibc
>       version of <stdlib.h> includes <alloca.h> and that contains
>       the line:
>
>           #define alloca(size)   __builtin_alloca (size)
>
>       with messy consequences if one has a private version of this function.
>
> This is nothing I want to have in any production software. OK, you
> may argument that U-Boot has a strictly controlled environment, but
> anyway.

Yes, I don't expect that we will allow a custom implementation of
alloca into U-Boot, but it's a good point that the compiler treats it
in strange ways.  One alternative here would be to always call
__builtin_alloca...  This would probably have other issues though.

> Third, the man page says:
>
> NOTES
>
>       The alloca() function is machine- and compiler-dependent. For
>       certain applications, its use can improve efficiency compared
>       to the use of malloc(3) plus free(3). In certain cases, it can
>       also simplify memory deallocation in applications that use
>       longjmp(3) or siglongjmp(3).
>       Otherwise, its use is discouraged.
>
> In my opinion, U-Boot falls into the "otherwise" category...

Yup, and another man page in the "Bugs" section says:

The alloca() function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.

Which seems even worse.  So, OK, I think we've run this to the ground.
 And we can always find and replace all of the uses of Mikes macro
easily if we think of something better later.

Thank you,
    Anton

>
>> I think I agree with this not being a great solution.  I do wonder if
>> it would be useful to consider a dedicated buffer management API that
>> could be used to allocate and free cache line aligned power of two
>> buffers.  Perhaps something like a buddy heap for simplicity.
>
> The longer I read this thread, the less frightening Mikes's macro
> becomes (compared tho the alternatives).
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "Though a program be but three lines long,
> someday it will have to be maintained."
> - The Tao of Programming
>