From: Ben Hutchings <ben@decadent.org.uk>
To: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
"kmcmarti@redhat.com" <kmcmarti@redhat.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"kyle@infradead.org" <kyle@infradead.org>,
"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>,
"linux-firmware@kernel.org" <linux-firmware@kernel.org>
Subject: Re: linux-firmware-i915 pull request (bxt dmc, kbl dmc)
Date: Wed, 03 Aug 2016 01:09:17 +0100 [thread overview]
Message-ID: <1470182957.4176.183.camel@decadent.org.uk> (raw)
In-Reply-To: <1470170876.5637.38.camel@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]
On Tue, 2016-08-02 at 20:48 +0000, Vivi, Rodrigo wrote:
> On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote:
[...]
> > Why are you deleting old versions?
>
> Mainly to keep it clean. OSVs pack that entire repo, I don't want i915
> taking unnecessary space from final users.
Any filename requested by a driver in a stable release of Linux should
not be removed from linux-firmware.git. If it's buggy then it should
be replaced it with a fixed version. I can envisage extreme cases
where we might make an exception but AFAIK this has not happened yet.
The OS vendor knows which kernel versions they want to support and
which files can therefore be dropped. I do that for Debian
periodically.
>
> 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.
Ben.
--
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-03 0:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 23:20 linux-firmware-i915 pull request (bxt dmc, kbl dmc) Vivi, Rodrigo
2016-07-05 13:43 ` Kyle McMartin
2016-07-06 23:36 ` Vivi, Rodrigo
2016-08-02 11:04 ` Jani Nikula
2016-08-02 20:48 ` Vivi, Rodrigo
2016-08-03 0:09 ` Ben Hutchings [this message]
2016-08-03 9:08 ` Jani Nikula
2016-08-03 15:02 ` Daniel Vetter
2016-08-03 15:06 ` Vivi, Rodrigo
2016-08-03 15:08 ` Daniel Vetter
2016-08-03 15:12 ` Vivi, Rodrigo
2016-08-03 15:26 ` Daniel Vetter
2016-08-03 15:48 ` Vivi, Rodrigo
2016-08-04 18:38 ` David Weinehall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1470182957.4176.183.camel@decadent.org.uk \
--to=ben@decadent.org.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=kmcmarti@redhat.com \
--cc=kyle@infradead.org \
--cc=linux-firmware@kernel.org \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox