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.
