Hey Gabe, I strongly agree that the way we configure gem5 is confusing and needs to be improved. I also like the idea of a menuconfig-like system for doing it. However, it seems to go against the other project you're working on. Namely, to make a single gem5 binary with all of the ISAs, etc. compiled in. If we could have a single build of gem5, I think that would be much better than a complex build system.
Relatedly, I think that working towards making gem5 more modular (e.g., Daniel's work to decouple the SimObjects for the last release) would be one of the most impactful changes to gem5. If we could build separate (shared?) libraries for each of the components (e.g., O3CPU, X86ISA, etc.) and then just discover which components are available at runtime, I think this would solve a huge number of our biggest pain points. Cheers, Jason On Wed, Jul 28, 2021 at 8:34 PM Gabe Black via gem5-dev <[email protected]> wrote: > (Sorry if this already went through. I accidentally sent it from a > different account the first time, and I think it got silently rejected by > the mailing list, or at least I couldn't find it in my email.) > > > > Hey folks. I've been thinking about how build configuration is handled > right now. Mostly this is done using files in build_opts (selected by the > name of the build subdirectory), and setting variables on the SCons command > line. > > This can be a bit tricky because there are variables which have sticky > values, variables which come from the environment, etc, and it's not always > clear what they are, what they do, what value they have, why, what values > they could have instead, etc. > > One feature we have now which helps, is that if you print out the help > message, our script will also dump all the config values. This is good, but > it's a little hidden, and is a big wall of text which can be confusing or > overwhelming itself. > > What I would like to do is to add some sort of explicit configuration > step/mechanism (think something like make config for the linux kernel) > which would let you browse around the config options, give them help text, > etc, and let you manage them in a more friendly environment than passing > them on the command line. > > This would also provide a lot cleaner mechanism for updating variant > specific variables. For instance, if you want to update the CPU list for > just x86, you'd need to do something like scons CPU_MODELS=.... > build/X86/gem5.opt. You would have to update the setting as part of a > build, and the build would have to specifically be part of build/X86, even > if you didn't want to build now, or wanted to build something else, like > maybe gem5.opt for all the arches. > > The downside to making the configuration mechanism more powerful is that > people will probably take advantage of that, and the number of ways gem5 > could be built will go way up (again, think make config for the linux > kernel). On the plus side, this will make a mechanism like letting people > turn on/off individual models, build parts of gem5 as modules, etc, *way* > more user friendly than having 10,000 USE_BLAH_BLAH flags on the command > line. > > Obviously there are many steps between here and there and I don't expect > to get there in one huge leap. Given that, what do people think of this as > far as a general direction? > > Gabe > _______________________________________________ > gem5-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
