Re: [PATCH 3/3] sandbox: work around missing of_add_memory_bank()

[Lucas Stach <l.stach@pengutronix.de>]

Am Dienstag, den 22.07.2014, 12:25 +0200 schrieb Holger Schurig:
> > but this doesn't explain a build failure
> 
> The build failure was
> 
>   LD      barebox
> drivers/built-in.o: In function `of_add_memory':
> /home/schurig/d/mkarm/barebox/drivers/of/base.c:1716: undefined
> reference to `of_add_memory_bank'
> collect2: error: ld returned 1 exit status
> make: *** [barebox] Error 1
> 
> To be honest, I simply assumed "sandbox has no memory banks, so adding
> them is futile" and commented them away. Two weeks ago (or so, not
> exactly sure) there was talk on the same function here in the mailing
> list. At that time there have been some other suggestions, but they
> made the MIPS arch not build. Sascha then said he had no further idea.
> 
> > CONFIG_OFTREE_MEM_GENERIC to be enabled on sandbox. Would
> > this work for you?
> 
> Yes, that worked. This now checks even more code than my #ifdeffery
> would have checked, so I like it.
> 
> Would then this be ok?
> 
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -4,7 +4,7 @@ config OFTREE
> 
>  config OFTREE_MEM_GENERIC
>         depends on OFTREE
> -       depends on PPC || ARM || ARCH_EFI
> +       depends on PPC || ARM || ARCH_EFI || SANDBOX
>         def_bool y
> 
I'm fine with this solution.

> 
> 
> Unrelated: which static checkers use you in non-kernel project?  I
> know sparse, but that isn't really usable outisde the kernel, or is
> it?
> 
Personally I've used smatch (it also needs to run a build), but don't
know how useful this is outside of a kernel/barebox source tree. My
current favorite is cppcheck as it doesn't need a build run and provides
a really good signal-to-noise level, but this also means it might
overlook some potential problems.
 
> I found clang's static checker giving out lots of warning, similar to
> -Wall -Weverything, e.g. he spits out things that aren't technically
> errors, but not clean code (e.g. assignment to a variable that is not
> used afterwards). But in my own code he found via reasoning some paths
> where a null-pointer dereference could happen, or a division by zero.
> That's something I don't want. BTW, clangs static checker finds also
> both things in barebox, I've had not yet the time to check if they are
> indeed possible. He also finds various places of usage of initialized
> variables. Some of them I checked, and they have been true. In the
> HTML output he writes exactly what circumstances must be valid to
> reach that specific point in the code. You cannot easily see that from
> what it spits to stdout.

Good to know. I think I'll give it another go after your patches are
accepted.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox