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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <004a2ef9c1e04f9ffbb9c3cc9907ca656a406713.camel@aparcar.org>
Date:   Tue, 07 Apr 2020 13:38:17 -1000
From:   Paul Spooren <mail@...rcar.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, robh+dt@...nel.org,
        jason@...edaemon.net, gregory.clement@...tlin.com,
        sebastian.hesselbarth@...il.com, daniel@...rotopia.org,
        freifunk@...ianschmutzler.de, kaloz@...nwrt.org
Subject: Re: [PATCH 0/5] arm: dts: linksys: rename codename to model

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.

What about the changed labels? Are they considered ABI too?

Regarding file names, I'm new to ABI policies. Within OpenWrt this is
all done via a single line patch, I'm not familiar with any other
installers/bootloaders. 

If renaming is a reason not to merge this I'd send a v2 containing only
the the added compatible list and updated labels.

Best,
Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ