On Tue, 2025-01-14 at 07:40 +0100, Gabriele Monaco wrote: > On Mon, 2025-01-13 at 16:34 -0500, John Kacur wrote: > > > > > > On Mon, 13 Jan 2025, Gabriele Monaco wrote: > > > > > Modules can currently be set only via configuration file, if rteval > > > is > > > called from a script run on different systems, the only way to make > > > sure > > > the loaded modules are known is to provide (or generate) a > > > configuration > > > file and pass it via -f/--infile . > > > > The config files are almost obsolete. > > Everything has a reasonable default, or can be set from the CMI > > The one exception is for the measurement module. > > > > What would be useful would be a CMI interface to switch from rtla > > timerlat > > to cyclictest. > > > > Mmh, that was actually my first idea, something like --measurement- > modules=timerlat,cyclictest --loads-modules=hackbench > Basically behaving just like the measurement and loads sections in the > config. > > I opted for this as it was simpler but if the config file is getting > obsolete, I think you can just ignore the patch. It's a simple enough patch that it might be worth taking anyway... unless we actually do want to deprecate the config file entirely, rather than just making sure it's not the only place where certain things can be configured. > > I could start drafting a patch for the CLI options to specify modules > if they look alright to you. > > Another not too different option could be kinda like stress-ng, > specifying the modules just like --cyclictest , --timerlat , -- > hackbench , etc. It fits the pattern of module-specific parameters, so I kind of like it from an interface perspective. Implementation wise, though, something like --load-modules='cyclictest,sysstat' or --load cyclictest --load sysstat might be easier (interface wise, I prefer the latter). > > Both would require a bit of refactoring how we load modules. That could be a good thing, if the new way is simpler. -Crystal
