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

[Wolfgang Denk <wd@denx.de>]

Dear Anton Staaf,

In message <CAF6FioWhhqbVQWWPrusb69S2mpfBtoiazxc8x56bkogJmzXZ3g@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.

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.

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...


> 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