[marc-hb]

Also add commented out "snd_sof sof_debug=1" example

Signed-off-by: Marc Herbert marc.herbert@intel.com

[marc-hb]

https://sof-ci.01.org/softestpr/PR734/build787/devicetest is all green.

v2 : small comment rephrase.

[plbossart]

why is this needed? We can already add module parameters in /etc/modprobe.d/alsa-base.conf

[fredoh9]

shift? is this required?

[marc-hb]

Yes to remove the module name from "$@" below

[marc-hb]

why is this needed? We can already add module parameters in /etc/modprobe.d/alsa-base.conf

This an alternative for faster changes locally. /etc/modprobe.d/alsa-base.conf is owned by root and by the Linux distribution (package alsa-base on Ubuntu). This is in sof-test.git source control. I don't run my editor as root and I can use git to track what parameters I changed like the rest of my local changes.

BTW we should avoid editing files owned by distributions first because scripting file changes is brittle and more importantly because conflicts with apt-get upgrade are a nightmare to resolve, even more so at the test farm scale. That's exactly why /foo.d/ directories exist: so you never have to edit files but add/remove them instead.

[plbossart]

why is this needed? We can already add module parameters in /etc/modprobe.d/alsa-base.conf

This an alternative for faster changes locally. /etc/modprobe.d/alsa-base.conf is owned by root and by the Linux distribution (package alsa-base on Ubuntu). This is in sof-test.git source control. I don't run my editor as root and I can use git to track what parameters I changed like the rest of my local changes.

to run sof-test you need sudo privileges...

BTW we should avoid editing files owned by distributions first because scripting file changes is brittle and more importantly because conflicts with apt-get upgrade are a nightmare to resolve, even more so at the test farm scale. That's exactly why /foo.d/ directories exist: so you never have to edit files but add/remove them instead.

we can move this to a separate file e.g. /etc/modprobe.d/sof-module-options.conf
the only requirement is that it's a file in that directory with the '.conf' extension.

I don't think we want to make the use of kernel parameters easier to be honest, and I don't think uncommenting a script would make it significantly better. There are other kernel parameters, e.g. to prevent pm_runtime, change the clock-stop mode, etc. Picking just sof_debug is quite limited.

[marc-hb]

to run sof-test you need sudo privileges...

Sure but you don't run git or your editor with "sudo".

There are other kernel parameters, e.g. to prevent pm_runtime, change the clock-stop mode, etc. Picking just sof_debug is quite limited.

This is just an example, this change supports any module.

I don't think uncommenting a script would make it significantly better.

This commit makes local changes much easier to do and track, I know because I've been using it a lot and I will keep using it locally in any case. It's way too easy to forget about /etc/ changes.

Speaking of which: this also reduces massively the risk of leaving shared systems inconsistent with each other.

I don't think we want to make the use of kernel parameters easier to be honest,

Right now I need the ability to turn the trace ON/OFF quickly and I'm not interested in switching to a different window and editor just for that (and then forget what's there). I can easily imagine having to do the same for other parameters in the future. If some things should be hard to change, why are there parameters for them in the first place?

[ujfalusi]

we could also look for non-tracked conf file in the directory and pick the options from there or have a tracked conf file (with only comments) for the same purpose so we will not need to edit the script itself which might be a pain (sort of) for pull/rebase

[marc-hb]

To clarify I agree with @plbossart that parameters shared across everyone should come from a single place: /etc/modprobe./d. I don't even know what happens when you have parameters in both /etc/modprobe.d/ and on the command line and I'm not sure I want to know. Maybe I should add a comment to make that clearer? This PR is only for local and temporary testing purposes, so git conflicts should be rare and small.

[ujfalusi]

Right, I can see this can be useful in some cases and before pull one can git stash or just git reset --hard or whatever.
But this is not a substitute for boot time parameters, you still need to go and modify the /etc/modprobe.d/abcd.conf and when you did that it will be applied to the sof_instert.sh.

[ujfalusi]

I can see the application and that it can be a time saver for certain use scenarios without side effect to others.

[ujfalusi]

@marc-hb, for me editing the sof_insert.sh or the /etc/modprobe.d/sof.conf is the same difference ;)

[marc-hb]

@marc-hb, for me editing the sof_insert.sh or the /etc/modprobe.d/sof.conf is the same difference ;)

Do you not use git from your editor? I couldn't live without it...