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

Wolfgang Denk
2011-08-29T20:35:58Z

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