But we know that 1.23 is bad and cause issues regardless the kernel version. And please keep in mind this is the most common case. Usually a previous minor version was dropped in favor of a new one because we found a bug that got fixed in a following minor version. This is the minor version idea. So regardless the kernel version, the newest minor is probably safest than the previous one. So, I don't want to keep all versions in linux-firmware.git, specially those that we know that cause bad issues. And here is the case were only symbolic link would help imho. On Wed, 2016-08-03 at 17:08 +0200, Daniel Vetter wrote: > On Wed, Aug 3, 2016 at 5:06 PM, Vivi, Rodrigo <rodrigo.vivi@xxxxxxxxx > > wrote: > > > > So, issues like https://bugs.freedesktop.org/show_bug.cgi?id=97182 > > > > will appear with frequency now... > > > > should we just close all as wontfix? > It sounds like we should fix that by restoring 1.23. Certainly not > WONTFIX. WONTIFXing regression is pretty much the only guaranteed way > to terminally piss of Dave&Linus. > -Daniel > > > > > > > On Wed, 2016-08-03 at 17:02 +0200, Daniel Vetter wrote: > > > > > > On Wed, Aug 3, 2016 at 11:08 AM, Jani Nikula > > > <jani.nikula@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe this is another point in favor of bringing the > > > > > > sym > > > > > > links > > > > > > back. > > > > > > > > > > > > But also because we need to remove any firmware that we > > > > > > know it > > > > > > is bad > > > > > > and that would break the user. If it was blacklisted it was > > > > > > removed > > > > > > from repo. > > > > > > > > > > > > Yet another reason for symbolic link. If we know the > > > > > > firmware > > > > > > is bad it > > > > > > is bad for previous versions as well, but if we stay with > > > > > > the > > > > > > version > > > > > > hardcoded we are forcing the user to stay with a firmware > > > > > > that > > > > > > we know > > > > > > it is bad. > > > > > Indeed. Please don't put a full version number in the > > > > > filenames > > > > > requested by drivers. Where it's not possible to maintain > > > > > ABI > > > > > compatibility between driver and firmware indefinitely then > > > > > include an > > > > > ABI version in the filename, but not the full version. > > > > I'm starting to sound like a broken record, but here goes > > > > again. > > > > > > > > We do not have the bandwidth to test all combinations of kernel > > > > and > > > > firmware versions. > > > > > > > > If we update linux-firmware to change the firmware blob to use > > > > (either > > > > by changing where the symlink points or by replacing the file) > > > > we > > > > roll > > > > out untested firmware/kernel combinations to stable kernel > > > > users. > > > > > > > > IMO we should be specific which firmware version(s) to accept > > > > in > > > > the > > > > kernel, limiting to known good and tested combinations. If > > > > there's > > > > a > > > > need to update the firmware to use for stable kernels, it's a > > > > matter of > > > > backporting the commit accepting another firmware version. This > > > > can > > > > be > > > > done by us or an OSV. > > > > > > > > Even when there's supposed to be ABI compatibility, I wouldn't > > > > liberally > > > > roll out firmware updates across all past stable kernels > > > > without > > > > testing. Anyone suggesting that obviously doesn't have to be in > > > > the > > > > receiving end of the bug reports when things go wrong in > > > > mysterious > > > > and > > > > non-bisectable ways. > > > > > > > > I don't think it's a good idea to give the control of firmware > > > > version > > > > selection to the user space and linux-firmware. > > > +1 > > > > > > We discussed why symlinks are not a great pick for gpus at > > > length, > > > all > > > those reasons are still valid. Mostly it boils down to that the > > > actual > > > interface between gpu components is _extremely_ wide, and > > > includes > > > all > > > kinds of fun things like minute timing details, w/a settings and > > > really just everything. > > > > > > I'd say for the same reasons we only support open source > > > userspace > > > drivers (anything else can't be audited when it breaks and > > > debugged) > > > we need to restrict the combinatorial interaction madness with > > > firmware. If that makes gpus special in yet another way, so be > > > it. > > > -Daniel > > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
