[U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing

[Simon Glass]

Hi Mike,

On Sun, Feb 26, 2012 at 8:08 PM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Sunday 26 February 2012 21:50:32 Simon Glass wrote:
>> Given your efforts on the cmdline parsing I'm beginning to think we
>> should perhaps add os_printf() and os_printf_stderr() and provide an
>> explicit interface. It might only be useful prior to main(), then
>> again I'm not so sure.
>
> i've been pondering this.  on one hand, we want to parse flags as soon as
> possible, but on the other, we want to be able to not have to worry about what
> state the system is in when parsing things.  maybe we specially mark the few
> flags that we need very early on and parse those, and then parse the rest once
> the system is mostly functional ?  i can really only think of one or two flags
> that we *might* need very early -- namely, ones that'd select a config or fdt.
> on the other hand, are there things that we'd want to change that'd affect
> everything from console_init_f() and earlier ?

IMO flags should purely update the initial state and therefore we
don't need the system to be function to parse them. Once the system is
functional, the various bits that are interested can go and look at
the state to get the info they want. IOW I don't think we need to
delay parsing until the system is functional - we just need to take
'action' then.

Anyway once we have a lot of test subsystems we are going to want to
have options in a config file.

>
> wrt os_printf/etc..., the only way we could do that is if we dlopen-ed glibc
> and called the symbol directly.  u-boot provides printf() so we can't have an
> os_printf() in os.c call printf() in glibc simply because we included stdio.h
> from glibc.

Yes that reminds me why I didn't do that last time. I was wondering
about using a link flag to rename the library version of the call but
it seemed a bit ugly.

Regards,
Simon

> -mike