command line options for layer23 apps

Harald Welte laforge at
Tue Oct 26 17:44:30 UTC 2010

Hi Christian,

On Tue, Oct 26, 2010 at 05:48:53PM +0200, Christian Vogel wrote:
> >therefore i like to leave all common options in common/main.c.
> >additional options i like to put in the individual app_*.c files. each
> >options i like to check at the individual app file. if it doesn't exist
> >there, the main.c checks if the option is a common option:
> >...
> >c = l23_app_handle_options();
> >if (c == -1)
> >        c = getopt_long(argc, argv, "hs:S:a:i:v:d:",
> >                    long_options, &option_index);
> >if (c == -1)
> >        break;
> >...
> To be honest, I don't like the idea of calling two different "instances"
> of getopt/getopt_long. But that's just me, probably.

I agree.

> What about a app-specific function to call early where the application
> can register the relevant options:
> 	/* in app.c, called before getopt is started */
> 	l32_app_setup_options(){
> 		l32_add_option('q',"quux",1); /* short, long, hasarg */
> 		l32_add_option('d',"debug",0);

yes, I would like that.  But don't make it layer23 specific but put it in
libosmocore.  This way, even individual code parts like the log file handling
can register their own options.  For the cross-compilation case we can simply
make all the functions no-ops.

> Of course it makes it more difficult to handle options where the meaning
> is position dependant, you have to keep state in global structures then.
> But we don't want to recreate ffmpeg, do we?

No, please don't do it.  We've done it for iptables, and it is a nightmare :)

- Harald Welte <laforge at> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the baseband-devel mailing list