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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a8cb67ed99d09de20583835a994586669f5dc0a5.camel@aparcar.org>
Date:   Thu, 09 Apr 2020 23:49:42 -1000
From:   Paul Spooren <mail@...rcar.org>
To:     Daniel Golle <daniel@...rotopia.org>, Imre Kaloz <kaloz@...e.hu>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "jason@...edaemon.net" <jason@...edaemon.net>,
        "gregory.clement@...tlin.com" <gregory.clement@...tlin.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "freifunk@...ianschmutzler.de" <freifunk@...ianschmutzler.de>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "kaloz@...nwrt.org" <kaloz@...nwrt.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "sebastian.hesselbarth@...il.com" <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH 0/5] arm: dts: linksys: rename codename to model

On Wed, 2020-04-08 at 17:23 +0100, Daniel Golle wrote:
> Hi Imre,
> 
> On Wed, Apr 08, 2020 at 08:32:41AM +0000, Imre Kaloz wrote:
> > Hi,
> > 
> > I'm on the same page here - this has not an issue for years. The
> > common sense and policy was always to reject kernel changes that
> > would only make the userland's job easier - and here were are not
> > even talking about the userland, but a script that's being used for
> > image generation.
> > 
> > The reason codenames are preffered to marketing names is simple:
> > the same board can be sold under multiple marketing names.
> > 
> > The Linksys Viper has been sold as E4200v2 and EA4500. The Linksys
> > Focus as EA6100 and EA5800. The LeMans is the EA6300 and the
> > EA6200. The Macan is both EA7500 and EA7400 - on the other hand,
> > the EA7500v2 and the EA7400v2 are the Savannah.
> 
> What Paul, Adian and others are trying to achieve here is
> consistency.
> See also the debate on openwrt-devel:
> 
> http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022567.html
> 
> The goal is to make it easier for users and semi-automated processes
> to identify the right OpenWrt image for a specific device.
> This especially becomes necessary for OTA updates and we have
> invested
> quite a bit of work to no longer need to scrape and translate that
> with additional layers of abstraction but simply use the first (ie.
> most significant) compatible from DTS to indentify the right image.
> 
> As product-name aliases are indeed very common, we usually deal with
> it
> in a way that the first product name which hits the OpenWrt tree is
> used for model, compatible, DTS- and image filenames. We then add
> aliases to that in our build-scripts which allows web-based wizards
> and
> such to match the alternative names as well when entered by the user.

I think if renaming of the label names is out of the questions (for ABI
stability), the situation becomes worse adding the OpenWrt profile-name 
as first item to the compatible list: The OpenWrt build system would
use internally `linksys_wrt3200acm` while other scripts for LEDs would
still use `rango`.

Therefore I'd suggest to reject the patch and I'll see if we apply them
within OpenWrt only or come up with something entirely different.

Thanks everyone for your time, this first Kernel patch run was a bit
exciting!

Stay safe & healthy,
Paul

> 
> 
> > 
> > Best,
> > 
> > Imre
> > 
> > ________________________________
> > From: Florian Fainelli <f.fainelli@...il.com>
> > Sent: Wednesday, April 8, 2020 2:07:38 AM
> > To: Paul Spooren <mail@...rcar.org>; Andrew Lunn <andrew@...n.ch>
> > Cc: devicetree@...r.kernel.org <devicetree@...r.kernel.org>; 
> > jason@...edaemon.net <jason@...edaemon.net>; 
> > gregory.clement@...tlin.com <gregory.clement@...tlin.com>; 
> > linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>; 
> > daniel@...rotopia.org <daniel@...rotopia.org>; 
> > freifunk@...ianschmutzler.de <freifunk@...ianschmutzler.de>; 
> > robh+dt@...nel.org <robh+dt@...nel.org>; kaloz@...nwrt.org <
> > kaloz@...nwrt.org>; linux-arm-kernel@...ts.infradead.org <
> > linux-arm-kernel@...ts.infradead.org>; 
> > sebastian.hesselbarth@...il.com <sebastian.hesselbarth@...il.com>
> > Subject: Re: [PATCH 0/5] arm: dts: linksys: rename codename to
> > model
> > 
> > 
> > 
> > On 4/7/2020 4:38 PM, Paul Spooren wrote:
> > > Hi Andrew,
> > > 
> > > thank you very much for the quick response!
> > > 
> > > On Wed, 2020-04-08 at 00:46 +0200, Andrew Lunn wrote:
> > > > On Tue, Apr 07, 2020 at 11:08:10AM -1000, Paul Spooren wrote:
> > > > > Linksys chose to use codenames for a few of their devices and
> > > > > sell
> > > > > their
> > > > > them under an entirely different name.
> > > > > 
> > > > > codename  model name
> > > > > rango  -> wrt3200acm
> > > > > mamba  -> wrt1900ac
> > > > > cobra  -> wrt1900ac-v2
> > > > > caiman -> wrt1200ac
> > > > > shelby -> wrt1900acs
> > > > 
> > > > Hi Paul
> > > > 
> > > > There was quite a bit of discussion about this when the first
> > > > board
> > > > was added. If i remember correctly, it was Mamba.
> > > > 
> > > > Imre Kaloz, <kaloz@...nwrt.org> was the one arguing for
> > > > the name armada-xp-linksys-mamba.dts.
> > > > 
> > > > So it seems that openwrt.org has now come full circle?
> > > 
> > > I talked with three currently active OpenWrt core developers and
> > > all
> > > were in favor of a unification. I wasn't aware of any previous
> > > discussions nor any pro arguments to keep code names.
> > > 
> > > I've added Imre via CC so maybe he can share his opinion, too.
> > > > > This introduces some extra loops in OpenWrt, a distribution
> > > > > specialized
> > > > > on embedded Internet facing devices, as both codename and
> > > > > model
> > > > > name are
> > > > > used within the build system. The double naming requires
> > > > > developers
> > > > > to
> > > > > keep track of that mapping and introduces inconsistencies:
> > > > > 
> > > > > To build a specific device in OpenWrt profiles are used,
> > > > > named
> > > > > after the
> > > > > the compatible string for targets using device tree (similar
> > > > > to how
> > > > > .dts
> > > > > files are named in the linux source tree). However, the first
> > > > > item
> > > > > of
> > > > > the DT `compatible` list in this case is `linksys,rango`,
> > > > > which is
> > > > > inconsistent with the model name and not what common users
> > > > > would
> > > > > expect.
> > > > > 
> > > > > Such double naming complicates currently the automatic search
> > > > > for
> > > > > firmware upgrade as the build system does not support such
> > > > > mapping.
> > > > > Ideally the first item of the DT `compatible` list would
> > > > > contain a
> > > > > string suitable to be used as a filename recognizable by
> > > > > normal
> > > > > users to
> > > > > belong to that device.
> > > > > With this patch set the Linksys device tree files are moved
> > > > > from
> > > > > containing the codename to contain a sanitized model name and
> > > > > also
> > > > > use
> > > > > it as first entry of the DT `compatible` list.
> > > > 
> > > > I've no problems adding another compatible to the list. But i
> > > > don't
> > > > like the idea of renaming the files. The file names could be
> > > > considered ABI! What installers/bootloaders are you going to
> > > > break by
> > > > renaming them?
> > > 
> > > Are you okay with adding the new compatible string as first
> > > element of
> > > the list? This would already simplify the OpenWrt build system.
> > 
> > Having a mapping table between model names in OpenWrt profiles and
> > .dts
> > file names in the kernel sources is not that complicated to
> > maintain,
> > changing the kernel for that reason sounds a bit weak IMHO.
> > --
> > Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ