New discussion proposal for u-boot summit: "switch malloc to succeed or die model, as glib does"
Hi All,
Sorry for the poor timing in bringing this up, but this just came up when discussing the review of some sunxi patches.
Ian asked me to add error handling for mmc_create failing, which, if used properly, only ever fails if calloc fails.
This made me thinking that we should switch u-boot to the glib memory alloc failure handling model, which is put a die() / abort() inside the low level malloc routines when they fail.
The reasoning is that if malloc fails, you're typically looking at a fatal error anyways, and this will allow removing error handling from a lot of higher level users, reducing code, and removing a lot of code paths which are in essence unused and as such also very much untested.
I guess there may be some special cases where we don't want the malloc_or_die behavior I'm advocating for, for those we could introduce a malloc_unchecked function.
Detlev any chance you could squeeze this into the schedule somewhere?
Regards,
Hans
Hi,
Quoted 5 lines · Hans de Goede
Hi All,
Sorry for the poor timing in bringing this up, but this just came up when discussing the review of some sunxi patches.
Quoted 7 lines
Ian asked me to add error handling for
mmc_createfailing, which, if used properly, only ever fails if calloc fails.This made me thinking that we should switch u-boot to the glib memory alloc failure handling model, which is put a
die()/abort()inside the low level malloc routines when they fail.
I remembered that I've already seen something like this in u-boot, so after some grepping around I've found that at least common/cli_hush.c already does this. It introduces a (private) xmalloc and xrealloc which have the malloc_or_die behavior.
Regards,
Hans
Hi Hans,
Quoted 17 lines
Sorry for the poor timing in bringing this up, but this just came up when discussing the review of some sunxi patches.
Ian asked me to add error handling for
mmc_createfailing, which, if used properly, only ever fails if calloc fails.This made me thinking that we should switch u-boot to the glib memory alloc failure handling model, which is put a
die()/abort()inside the low level malloc routines when they fail.The reasoning is that if malloc fails, you're typically looking at a fatal error anyways, and this will allow removing error handling from a lot of higher level users, reducing code, and removing a lot of code paths which are in essence unused and as such also very much untested.
Quoted 6 lines
I guess there may be some special cases where we don't want the
malloc_or_diebehavior I'm advocating for, for those we could introduce amalloc_uncheckedfunction.Detlev any chance you could squeeze this into the schedule somewhere?
I'll note it for the list of things to discuss in the discussion round in the evening.
Cheers
Detlev
Signature · 7 lines
(let ((s "bottles of beer on the wall")) ((lambda (f) (f f 99)) (lambda (f i) (or (= i 0) (format #t "~a ~a - take one down pass it around ~a ~a\n" i s (- i 1) s) (f f (- i 1)))))) -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de