So, issues like https://bugs.freedesktop.org/show_bug.cgi?id=97182 will appear with frequency now... should we just close all as wontfix? 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
