On 19/10/2022 12:51, Cezary Rojewski wrote: >> That's not necessarily a valid assumption, it's perfectly possible that >> a specific OEM decides to allocate more budget for a specific feature >> and less for others, resulting in libraries that are recompiled, >> optimized or configured differently. The UUID is a weak notion here, as >> measured by the same UUID being used for different DSP generations. >> Nothing prevents someone from generating a slightly different library >> exposed with the same UUID. >> >> We didn't want to restrict our partners and gave them with the ability >> to put both the base firmware and the libraries in different directories >> and overload the default path should they wish to do so. They could >> decide to point to the same directory if they wanted to. That's not our >> decision. >> >> If you look at all recent evolutions, we initially introduced different >> paths for firmware, then topology, then firmware and topology names. The >> logic of adding more flexibility for library path follow the pattern of >> trying to avoid making assumptions we have to undo at a later point. > > Thanks for the elaborate input. The evolution sound good, and is > perfectly reasonable. My only feedback is - should we put everything > under /intel directory? If all the paths can be customized, then the > parent directory needs not to be the same for every firmware package > regardless of its origin. It's counterintuitive, is it not? at the moment: # ls -al /lib/firmware/intel/ | wc -l 108 We might have 2 sets of binaries per platform, one using product key, other using community key. If we dump everything in one directory (/lib/firmware/intel/), things will go out of hand pretty easily which can be somehow handled with complex file naming. This is only for the basefw, then we have the libraries (however they are sourced) with again two sets of keys, platforms. Surely it can be done, but historically SOF prefers to use directories instead of pre/mid/post-fixing patterns of file names. Also note that SOF is looking for a module UUID when trying to load a library we don't track arbitrary file names (see cover letter). Does this make sense to you? -- Péter
