[Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

[Herbert, Marc]

Versioning dependencies isn't exactly a new problem outside the kernel,
so please allow me to share my experience below. Thanks to Rodrigo for
glancing over this email and preventing me from writing anything too
stupid or that was said already.


>> The firmware should be side-ways compatible for
>> everything with the same minor version (thus resolvable from the same
>> symlink), right?
> 
> From the same major version I guess it should, but the reason things
> don't work that way is why we introduced version white listing.

In an ideal world you look only at the major version of your dependencies
since they mark ABI changes. This is what the firmware symbolic links do.

Back to the real world, some minor versions are so bad that you
really don't want to inflict them on your users. So you go and blacklist at
the hardest level: in the source code itself. Fine.
However keep in mind blacklisting should stay exceptional since leaking
system configuration into source code means taking away from users control
they normally have. You need a pretty strong reason for this like some very
obscure bugs that can't be Googled easily or some "less than alpha" version.
Please keep in mind it's a hack/workaround: blacklisting shouldn't
never become a normal policy.

On the other hand, never WHITE-list since it blocks users from *UPGRADING*
the dependency.

If you're tempted to white-list the most current version then just blacklist
all versions older than today and job done. White-listing is making a very bold
and most likely wrong statement about the future: that no future revision
of the dependency will ever be a pure bugfix and fully compatible with the
current revision.

Please don't try to abstract away the independent versioning of the
firmware and make it look like firmware and kernel are developed, versioned,
released and validated on the same cycles and by the same team.
Granted: it's important to publish which versions
were validated together. However most software projects don't embed
their validation results in their source code as a default policy,
there are better ways to document things like this.

>> No. You want to be changing exactly one variable, which means leaving
>> the firmware constant.

Yes! Constant at least for a range large enough for bisections to be
practical (ABI changes happen too).

> Hm, not sure. When looking for a working snapshot you also want to
> consider bugs introduced by the firmware itself. This is in a way the
> exact reason why we want stricter control on the firmware version and
> introduced a white list. This also means that loading a firmware
> version other than what the driver allows (at a given commit) won't
> work anyway.

Please trust and respect your users. If someone is technical and motivated
enough to bisect the kernel and/or the firmware then please don't get
in her way and trust that she will: 1. try the latest releases first,
and 2. more generally have some clue about what she's doing. Or at
least learn quickly enough.

Again feel free to blacklist the known broken past but don't block the
unknown future, thanks!

Marc