[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hy2fm3hcc.wl-tiwai@suse.de>
Date: Wed, 17 Feb 2021 15:21:39 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Luis Chamberlain <mcgrof@...nel.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/4] firmware: Add the support for ZSTD-compressed firmware files
On Wed, 17 Feb 2021 15:17:52 +0100,
Greg Kroah-Hartman wrote:
>
> On Wed, Feb 17, 2021 at 02:34:34PM +0100, Takashi Iwai wrote:
> > On Wed, 17 Feb 2021 14:24:19 +0100,
> > Luis Chamberlain wrote:
> > >
> > > On Wed, Jan 27, 2021 at 04:49:36PM +0100, Takashi Iwai wrote:
> > > > Due to the popular demands on ZSTD, here is a patch to add a support
> > > > of ZSTD-compressed firmware files via the direct firmware loader.
> > > > It's just like XZ-compressed file support, providing a decompressor
> > > > with ZSTD. Since ZSTD API can give the decompression size beforehand,
> > > > the code is even simpler than XZ.
> > > >
> > > > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> > >
> > > It also occurs to me that having a simple like #define HAVE_FIRMWARE_COMPRESS_ZSTD
> > > on include/linux/firmware.h would enable userspace to be aware (if they
> > > have kernel sources) to determine if the kernels supports this format.
> >
> > Extending that idea, we might want to have a sysfs entry showing the
> > supported formats instead? This will allow to judge dynamically.
>
> What could userspace do with that information?
Decide whether to store the firmware files on the system in the
supported compression format or not.
But admittedly it can be little help, as that's rather information you
want not for the running kernel but for the system to be installed...
Takashi
Powered by blists - more mailing lists