Dne 08. 04. 21 v 17:32 Pierre-Louis Bossart napsal(a): > > > On 4/8/21 10:01 AM, Jaroslav Kysela wrote: >> When we have a common standard layer for the plug-and-play handling (udev), we >> should concentrate to allow changing / refining of this information there. >> Those strings are not used for anything else than the user space. So from my >> view, there's no reason to create another mechanism to handle the overrides. >> It should be a safe, fast, flexible and_optional_ solution. The udev can >> alter the sysfs attributes directly without any hassle with the file >> modifications or looking for another way to pass / store this information >> somewhere. > > There's one part where I am lost. > > The initial idea of udev what to modify kernel parameters to pick a > different path for firmware/topology before probing the PCI driver. At This may be a problematic point. The kernel cmdline cannot be modified from udev (as far as I know). The module parameters can be set using modprobe's config files or when loaded with sysfs attributes (/sys/module/*/parameters). Eventually, you can call the modprobe command with custom module parameters when the appropriate MODALIAS is probed. Perhaps, I'm missing something here, too. Some example udev rules may help. > that point there is no card and no sysfs attributes just yet, they will > be added at a later point during the probe itself. > > So are we talking about a second set of rules that would be applied when > the card is created? Yes, I'm talking about rules which depends on the sound driver specific sysfs attributes (you can match the modified /sys/module/*/parameters here). Jaroslav -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
