Re: Make rumpbake more flexible

  • From: Wei Liu <wei.liu2@xxxxxxxxxx>
  • To: Antti Kantee <pooka@xxxxxx>
  • Date: Thu, 27 Aug 2015 11:45:51 +0100

On Thu, Aug 27, 2015 at 10:15:40AM +0000, Antti Kantee wrote:

On 27/08/15 09:56, Wei Liu wrote:
Hi all

Currently all targets of rumpbake are hardcoded. That means I can't
control what rump components are linked in to the final binary. That's
not very desirable for power users. Being the first one to have such
needs I can certainly foresee other users in the future want to do the
same.

Can you define "hardcoded"? They're in a config file. They need to be
specified somehow, unless you intend the opposite of hardcoded to be "give
all components on the command line".


Hardcoded as in user doesn't have easy way to configure what he / she
wants unless he / she knows implementation detail of rumpbake.

I was thinking there should be at least a way to give all components on
the command line. Having some kitchen sink options for users is fine and
orthogonal to the improvement.

I would like to make rumpbake more flexible. That could be done by
either getting rid of the positional arguments or making it accept user
provided config file.

Can you elaborate what "Getting of the positional arguments" means?


Currently the syntax is

rumpbake TARGET OUTPUT FILE ...

i.e. all arguments are positional.

We can change to something like

rumpbake -t TARGET -o OUTPUT -c COMPONENT_LIST -f FILE ...

or

rumpbake -t TARGET -o OUTPUT -c USER_SUPPLIED_CONFIG -f FILE ...

Just something off the top of my head.

The syntax of rumpbake being experimental means we can get away with any
breakage at this stage.

If we add something like rumpbake -c myconfig, it won't even break anything.
Doing so will, however, "export" the config file format, but I think we're
allowed to break the format later, as long as things are marked
experimental.


That's right.

But I would also like to stabilise the syntax at some point. That's
another topic.

Wei.


Since the subject is "make rumpbake more flexible", there's also another
issue which we've been discussing with Sebastian. It's a mostly separate
discussion, and if someone wants to discuss it further, please start another
thread. I'm just giving it as an example of how we probably still need to
change the config file syntax. There should be some additional structure
which allows associating configs more specifically with boards. For
example, the set of device drivers appropriate for x86 platforms is not the
same as for ARM boards. Furthermore, there is variation between ARM boards.
So, hw_generic is not actually hw_generic, it's something like
hw_x86_pc_generic.

Other related posts: