lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <s5h4liypgev.wl-tiwai@suse.de>
Date:   Wed, 23 May 2018 16:58:48 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Guenter Roeck <groeck@...gle.com>
Cc:     pierre-louis.bossart@...ux.intel.com,
        Mark Brown <broonie@...nel.org>, alsa-devel@...a-project.org,
        Guenter Roeck <groeck@...omium.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        "Patel, Chintan M" <chintan.m.patel@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Wed, 23 May 2018 16:49:35 +0200,
Guenter Roeck wrote:
> 
> On Wed, May 23, 2018 at 6:56 AM Takashi Iwai <tiwai@...e.de> wrote:
> >
> > >
> > > My point was a bit different: distributions like Gallium start without
> > > the relevant topology files and UCM settings, and we should have a
> > > reference to quickly enable audio without having to borrow and modify
> > > files from another distro. I faced this issue when I worked with the
> > > Gallium folks to enable audio on Rambi and Cyan Chromebooks and
> > > ended-up creating this reference myself.
> >
> > This sounds rather like a question how the upstream distributes the
> > stuff properly...
> >
> Not really, or not only. My problem, in particular, is that I want (need)
> to be able to run different kernel versions with the same distribution, and
> I want to be able to swap kernel versions without having to update the root
> file system. That doesn't work if I have to use v4 configuration files for
> v4.4 and older kernels, and v5 configuration files for v4.9 and later
> kernels (besides, as I mentioned, that the v5 configuration files I found
> were all incomplete). In my opinion, thre should be exactly one
> configuration file for a given device, and there should be no need for
> users (or distributions) to hunt for the correct version of the file.

No doubt about the kernel backward compatibility, it should be
supported.

It's another problem, though, that downstream takes some wild stuff
without properly upstreaming.  A known story everywhere.


Takashi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ