[OpenWrt-Devel] Migration in ath79 for swapped ethernet

[Piotr Dymacz]

Hi Adrian,

On 28.01.2020 16:48, Adrian Schmutzler wrote:
> Hi Piotr,
> 
>> -----Original Message-----
>> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On
>> Behalf Of Piotr Dymacz
>> Sent: Montag, 27. Januar 2020 21:45
>> To: Adrian Schmutzler <mail at adrianschmutzler.de>
>> Cc: openwrt-devel at lists.openwrt.org; gch981213 at gmail.com;
>> ansuelsmth at gmail.com; 'David Bauer' <mail at david-bauer.net>
>> Subject: Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
>> 
>> Hi Adrian,
>> 
>> On 27.01.2020 19:35, Adrian Schmutzler wrote:
>> > Just a quick one:
>> >
>> >> > So, no matter what we do, there is no easy way forward.
>> >>
>> >> We could remove all ar71xx -> ath79 migration helper scripts, ar71xx
>> >> board names from supported devices lists in ath79 images and make the
>> >> target a brand new, without any concerns about soon-to-be obsolete ar71xx
> ;)
>> >
>> > At the moment, I'm actually mostly inclined towards this solution.
>> 
>> I'm afraid it's a bit late for that as 19.07 is already out and it
>> supports (at least partially) ar71xx -> ath79 migration path/s.
>> Wouldn't that look unprofessional? Am I overreacting here?
> 
> One didn't have to use -F during sysupgrade, but the release notes gave the
> clear advice to upgrade without keeping settings.
> So, IMO we actually didn't "support" any migration in 19.07.0.

Fair point.

>> > However, for me personally SUPPORTED_DEVICES was always more a "don't
>> brick entirely" flag, so I never expected it to ensure 100 % config
> compatibility.
>> More like preventing me from flashing ubnt,unifi image onto
> tplink,wdr-4300-v1.
>> This impression might have been wrong, though.
>> 
>> I think device to image matching was the main reason behind the idea.
>> IIRC, mismatched image doesn't prevent you against upgrading with
>> preserved settings.
>> 
>> > But as mentioned by Ansuel, there are other incompatible switches to come
>> (and some are already waiting), and unless we want to create new targets or
>> rename devices in these cases, we have to think about different "levels" of
>> compatibility anyway beyond ar71xx->ath79.
>> 
>> I believe ar71xx -> ath79 is a special case here. First of all, that's a
>> new DTS-enabled target and it was suppose to _replace_ ar71xx but 19.07
>> went out with both of them and I'm pretty sure there are users who got
>> confused with that (some devices are supported only in one of the
>> targets, some in both, some with seamless migration possible). On the
>> other hand, when ar71xx gets abandoned, we (as a project) should make it
>> clear if ath79 is a replacement (thus providing seamless upgrade from
>> ar71xx) or a new target, without any relationship with ar71xx (thus a
>> clean sysupgrade is required). Keeping anything in between would just
>> confuse people.
> 
> I do not really see a viable/desirable option to support eth migration at the
> moment. And I'm not really a fan of adding lots of migration stuff which spoils
> the new ath79 target already, so after all I think I also do not _want_ to add
> eth migration either.

I wouldn't want to introduce _now_ any extra 'migration' scripts, code, 
etc. All I really want is to keep mapping of physical interface to 
kernel interface name consistent with previous releases as this is the 
most important thing when you perform upgrade on e.g. remote-only 
accessible devices (or those on mast connected with single eth cable). 
And it's not only about 19.07 and 18.06. There are devices in ar71xx 
which got supported before the LEDE 17.01 release and I'm working on 
keeping them alive within ath79 target.

> So, I'd prefer to see the ath79 new and clean.
> 
> However, from the wording perspective, I do not think that a "replacement" means
> seamless upgrade. I'd thus keep the SUPPORTED_DEVICES just as a device-matching
> measure, but wouldn't implement any sophisticated migration despite that. Having
> SUPPORTED_DEVICES might actually be valuable for certain third parties, like I'm
> involved in a downstream project that regenerates the system/network config at
> each upgrade, but still exploits SUPPORTED_DEVICES for having the correct image.

If you prefer 'new and clean' ath79 then _IMHO_ ar71xx board names must 
be removed from SUPPORTED_DEVICES lists together with migration scripts 
in ath79. If downstream projects want to keep that 'mess', it would be 
up to them. It should be clear that the ath79 target isn't associated 
with ar71xx. IMHO, anything in between would be only an unmaintainable 
mess (just see your recent fixes regarding SUPPORTED_DEVICES in ath79: 
[0], [1]).

> And I could well live with keeping the already present migration scripts, as
> having them as "undocumented feature" won't hurt. If we do not advertise it, it
> won't confuse people ...

This smells for me like something easy to forget which would then get 
removed ~few years later during some gardening performed by newcomer 
without any knowledge about very-long-time-ago-dropped ar71xx :)

[0] https://git.openwrt.org/47935940d67147e3ec8dbfcb56ae14f1235369c5
[1] https://git.openwrt.org/da5b5ae9b9647f50853bff96309d1435cddcefce

-- 
Cheers,
Piotr

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel