Hi Masahiro, On 30 October 2014 01:53, Masahiro Yamada <yamad...@jp.panasonic.com> wrote: > Hi Simon, > > > > On Wed, 29 Oct 2014 19:43:26 -0600 > Simon Glass <s...@chromium.org> wrote: > >> Hi Masahiro, >> >> On 29 October 2014 08:06, Masahiro YAMADA <yamad...@jp.panasonic.com> wrote: >> > Hi Simon, >> > >> > 2014-10-29 3:24 GMT+09:00 Simon Glass <s...@chromium.org>: >> >> Hi, >> >> >> >> On 28 October 2014 11:46, Jeroen Hofstee <jer...@myspectrum.nl> wrote: >> >>> Hello Simon, >> >>> >> >>> >> >>> On 28-10-14 18:33, Simon Glass wrote: >> >>>> >> >>>> Hi Masahiro, >> >>>> >> >>>> On 28 October 2014 10:38, Masahiro YAMADA <yamad...@jp.panasonic.com> >> >>>> wrote: >> >>>>> >> >>>>> Hi Simon, >> >>>>> >> >>>>> >> >>>>> 2014-10-29 1:29 GMT+09:00 Simon Glass <s...@chromium.org>: >> >>>>>> >> >>>>>> Hi Masahiro, >> >>>>>> >> >>>>>> On 28 October 2014 10:25, Masahiro YAMADA <yamad...@jp.panasonic.com> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> Hi Gabe, Simon, >> >>>>>>> >> >>>>>>> >> >>>>>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <s...@chromium.org>: >> >>>>>>>> >> >>>>>>>> From: Gabe Black <gabebl...@chromium.org> >> >>>>>>>> >> >>>>>>>> inttypes.h defines format specifiers for printf which work with data >> >>>>>>>> types of >> >>>>>>>> particular sizes. stdlib.h is currently just a passthrough to >> >>>>>>>> malloc.h >> >>>>>>>> which >> >>>>>>>> has declarations of the various *alloc functions. >> >>>>>>>> >> >>>>>>>> Add the required #define to common.h so that these printf format >> >>>>>>>> specifiers >> >>>>>>>> will be made available. >> >>>>>>>> >> >>>>>>>> Signed-off-by: Gabe Black <gabebl...@google.com> >> >>>>>>>> Reviewed-by: Gabe Black <gabebl...@chromium.org> >> >>>>>>>> Tested-by: Gabe Black <gabebl...@chromium.org> >> >>>>>>>> Reviewed-by: Bill Richardson <wfric...@google.com> >> >>>>>>>> Signed-off-by: Simon Glass <s...@chromium.org> >> >>>>>>>> (Replaced with a GPL version from glibc) >> >>>>>>>> >> >>>>>>> [snip] >> >>>>>>>> >> >>>>>>>> diff --git a/include/stdlib.h b/include/stdlib.h >> >>>>>>>> new file mode 100644 >> >>>>>>>> index 0000000..6bc7fbb >> >>>>>>>> --- /dev/null >> >>>>>>>> +++ b/include/stdlib.h >> >>>>>>>> @@ -0,0 +1,12 @@ >> >>>>>>>> +/* >> >>>>>>>> + * Copyright (C) 2013 Google Inc. >> >>>>>>>> + * >> >>>>>>>> + * SPDX-License-Identifier: GPL-2.0+ >> >>>>>>>> + */ >> >>>>>>>> + >> >>>>>>>> +#ifndef __STDLIB_H_ >> >>>>>>>> +#define __STDLIB_H_ >> >>>>>>>> + >> >>>>>>>> +#include <malloc.h> >> >>>>>>>> + >> >>>>>>>> +#endif /* __STDLIB_H_ */ >> >>>>>>>> -- >> >>>>>>>> 2.1.0.rc2.206.gedb03e5 >> >>>>>>> >> >>>>>>> >> >>>>>>> This patch is not clear to me. >> >>>>>>> >> >>>>>>> Why do we need include/stdlib.h ? >> >>>>>> >> >>>>>> This makes the U-Boot environment more similar to that used by other >> >>>>>> software, so we can more easily build it without lots of glue files. >> >>>>>> Normally stdlib.h defines malloc() and friends. >> >>>>> >> >>>>> I am not happy about this. >> >>>>> >> >>>>> Our right direction is to make U-Boot environment more similar to the >> >>>>> Kernel, I think. >> >>>>> >> >>>>> stdlib.h shouldn't appear in bare metal code. >> >>>> >> >>>> That's right, we don't want to include this in U-Boot itself. But if >> >>>> you look at things in tools/ they include stdlib.h. With this header >> >>>> available, we can more easily compile external code into U-Boot. >> >>> >> >>> >> >>> So is it intended as fallback if the host doesn't have a stdlib.h? >> >> >> >> Not really, more that for things that expect that header (and >> >> inttypes.h which was also added) they can get it without needing >> >> special #ifdefs for U-Boot. >> >> >> > >> > >> > Sorry, I still don't get it. >> > Could you explain user cases? >> >> If you have a C file which has '#include <stdlib.h> in it, because it >> builds in another project as well as U-Boot, and needs mallloc(), then >> you want to build it with U-Boot and include <common.h>, etc. then you >> need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project. >> I am trying to make is easier for this case. This is a minor point, >> but little fish-hooks can be frustrating. >> > > I understand what you want to do, > but I am not sure if this is a right decision. > > Mixing the same header name sometimes causes a mess.
That's true although I don't really see a big issue here. IMO image.c and the like suffer from having two sets of headers - one for building in U-Boot and one for building outside. I thought maybe the solution was do have a section in common.h to deal with the differences, but then when I looked more I wasn't sure it was an improvement... Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
