On the other hand, the node of sysfs is quite common in Linux because
it's tightly coupled to kernel objects. Let you see files under
'Documentation/ABI/'. We can find efforts to maintain sysfs node so
safe and stable. Due to this reason, it's better to take more care when
adding new node.
Would I request you the reason to add this node and the reason that
current ALSA control interface doesn't satisfy your requirement?
simplicity for user support. Anyone can peak at a sysfs file, not everyone
is familiar with the alsa control interface.
We get lots of bug reports from people who are asking for configuration
help, and the simpler the command is the better.
For my information, would I request you to disclose the part of such reports?
I need supplemental information about the reason to add the alternative
path to expose it, especially the reason that no developers work to
improve existent tool relevant to UCM and are going to wish to add the
alternative without utilizing ALSA control character device.
I don't understand your question, sorry. UCM already uses the control
interface, it's not a matter of adding a new interface but making it
easier to visualize the contents reported by the machine driver.
See for example
https://github.com/alsa-project/alsa-ucm-conf/blob/4722f5b3859903521ba0f92a64d86af31083ca50/ucm2/sof-hda-dsp/HiFi.conf#L145
when people report that their microphone is not reported by
PulseAudio/UCM, it's very helpful to know what UCM was supposed to use
in the first place. We don't have a debugger or step-by-step mechanisms
to figure out what the configurations are.
There is zero intent to advertise this sysfs node as a basis for
applications to bypass the control interface, if that was what you
thought I was promoting.
