Hi, sorry for taking a while to reply to this. I think this is a good idea if kept small/limited, but has a lot of potential for abuse. gem5 seems to oscillate (over long periods of time) between command line arguments and languages/files to configure itself. People want command line options because they're easy to adjust from the command line, but then they're too limited and there are too many of them, so then the add a layer of scripts on top of that to set all the options. But then they want to be able to adjust what they're scripts do, and so they add command line arguments. And then somebody else comes along and doesn't want to mess with any of the things that exist, so they add a script on top of the arguments on top of the script on top of the arguments on top of gem5, perhaps in the form of a Makefile, local bash script, etc. The tower gets taller and taller, and more and more fragile, etc.
However, I think this idea has the potential to short circuit that cycle a bit by making it possible to have a very simple but very general purpose command line argument that lets you make small adjustments to a script without having to add a knob for every little thing. If, however, it gets to be more and more powerful (filters, wildcards, then small lambdas, etc.) it just turns into a tortured little scripting language in and of itself which is even worse than just using a real language like python. If you're doing something more complicated, you should just bite the bullet and modify the underlying script. So, after some thought, I think this is an idea worth pursuing, and its scope should be carefully limited and controlled. Gabe On Wed, Sep 26, 2018 at 7:01 AM Andreas Sandberg <[email protected]> wrote: > Hi Everyone, > > One of my colleagues just posted a couple of RFC patches [1, 2] that > introduce functionality to override SimObject param values from the > command line. These patches aim to solve the explosion of command line > arguments that tend to build up in example scripts when people want to > tune various parameters. I'd like to start a discussion around these > features and some feedback from the wider gem5 community. > > There has been talk about adding this type of functionality, both on > the dev list and offline, for quite some time. I am of the opinion that > there should be a clear distinction between structural configuration > (instantiating objects and wiring ports) and parameter tuning. For that > reason, these changes don't provide a mechanism to instantiate new > SimObjects. Structural configuration is left to the configuration script. > > It supports simple statements like "test_sys.cpu[0].socket_id = 2". > Unlike "normal" Python statements, you can operate on multiple > SimObjects at the same time using Python's slice syntax. For example, > "test_sys.cpu[0:3].socket_id = 2" sets the socket_id param on CPU 0-2. > In addition to slicing, it's posssible to select multiple indices: > "test_sys.cpu[0,1,2].socket_id = 2" > > The current mini-language is a proof-of-concept and build uses a custom > Python eval environment to override parameters. The implementation > ensures that it only operates on SimObjects and Params. Other object > attributes cannot be overridden. > > It would be really cool to have a richer language (e.g., something like > similar to XPath or ObjectPath[3]) to select objects with specific > properties. The current implementation tries to balance implementation > simplicity and usability by (ab)using eval in a limited environment. If > you know of a better way of doing this, please let us know. > > Cheers, > Andreas > > [1] https://gem5-review.googlesource.com/c/public/gem5/+/12984 > [2] https://gem5-review.googlesource.com/c/public/gem5/+/12985 > [3] http://objectpath.org/ > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
