On 10/18/22 10:46, Cezary Rojewski wrote: > On 2022-10-18 3:49 PM, Péter Ujfalusi wrote: >> On 18/10/2022 15:38, Amadeusz Sławiński wrote: > > ... > >>> I'm not sure that I understand the rationale here, can't libraries be >>> kept in the same directory as FW, as far as I know they are version >>> locked to FW anyway. I am not sure what 'version lock' means, nor who determines the version of the base firmware. The base firmware is not necessarily compiled by Intel in an SOF/open-source context. >> During the internal review we arrived to this setup, to keep the >> libraries separate from the basefw binary. >> One of the reason is that SOF project is not likely not going to release >> external libraries, they are mostly vendor/product locked. >> To make the life easier for the vendors (and distributions, packagers) >> we concluded that it is better to keep them separate. >> >> The option is there to specify custom path as well in case it is needed. > > Thanks for detailed answer, Peter. My two cents: > > I'd say the origin of the library has a saying in that. If it's > implemented by a vendor then it's simply not our decision. If it's made > by us (Intel), it's highly probable that there's no problem with sharing > the library. Library alone is often not enough - to process data as > expected on the specific hardware, additional configuration is needed. > We share that information over SRAM between the driver and the firmware. > And that's the key bit that should not be shared here. We should not debate on this mailing list what can or cannot be released, not make any distinctions between Intel and others. The library handling mechanism is generic, who provides the libraries is irrelevant. > As the basefw makes use of different prefixes when compared to the > libraries, I believe it's fine to leave as is. If an error is made when > differentiating between dsp_fw_* and dsp_lib_* then introducing avs-lib/ > is not going to help here. It's also much less hassle with matching the > basefw and lib versions if you have them both within single folder, > granted both target same AudioDSP generation (SKL-based, APL-based etc.). You're assuming that it's the same exact set of binary libraries for all skews based on the same SOC. 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. >>> In avs driver when we decided on intel/avs/platform >>> path we planned to keep FW related libaries there... >> >> My initial approach was this as well, but after a long debate it got >> revised. > > Amadeo: have my bow.. > Czarek: ..and my axe.. I don't understand what bow and axe have to do with this discussion. Let's say civil, shall we?
