Release goals for 22.XX
Paul Spooren
mail at aparcar.org
Tue Oct 19 19:47:17 PDT 2021
On 10/5/21 12:32 PM, camden lindsay wrote:
> Is - ipq807x a typo? i don't see this target in the snapshots... is
> it really ipq806x?
>
> many thanks
>
>
> On Tue, Oct 5, 2021 at 3:14 PM Paul Spooren <mail at aparcar.org
> <mailto:mail at aparcar.org>> wrote:
>
> Hi all,
>
> based on my overview[1] things are moving forward and being tested,
> great! What about the targets that did not see any 5.10 ambitions
> yet?
> Specifically:
>
> - arc770
> - archs38
> - ath25
> - bcm47xx
> - bcm4908
> - ipq807x
> - layerscape
>
For now layerscape is still on 5.4 without Kernel 5.10 support. Is
anyone planing to add support? Please reach out.
> - pistachio
> - uml
>
> Is anyone aware of people working on those targets? Please let me
> know.
>
> Best,
> Paul
>
> [1]: https://github.com/aparcar/openwrt/issues/15
> <https://github.com/aparcar/openwrt/issues/15>
>
> On 9/29/21 10:28, Hauke Mehrtens wrote:
> > Hi,
> >
> > The OpenWrt 21.02 release is done and we should plan the next
> release.
> > We already talked about this in the last meeting, see
> > https://openwrt.org/meetings/20210920
> <https://openwrt.org/meetings/20210920>
> >
> > To monitor the current state I created this wiki page based on the
> > wiki page from the previous release:
> > https://openwrt.org/docs/guide-developer/releases/goals/22.xx
> <https://openwrt.org/docs/guide-developer/releases/goals/22.xx>
> >
> > I would like to get an overview about the "big" changes, if an
> > additional board is added or something is improved we do not
> need to
> > plan it.
> >
> > I would like to get the following:
> >
> > kernel 5.10:
> > We should get all targets to kernel 5.10. All targets which are
> not on
> > kernel 5.10 when we branch off should get removed.
> >
> > Kernel version for all targets:
> > Kernel 5.10 (only):
> > bmips
> > Kernel 5.10 (5.4 still present):
> > bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86
> > Testing 5.10:
> > apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta
> > mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi
> tegra
> > Kernel 5.4 only:
> > arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap
> > pistachio uml zynq
> >
> > toolchain:
> > We already updated the toolchain in master to GCC 11.2, binutils
> 2.37
> > and musl 1.2.2. This looks good to me. Minor version updates of
> musl
> > libc later should be ok. gdb and glibc could also be update
> later if
> > someone wants to do it.
> >
> > mac80211:
> > I would like to update the mac80211 version we use to match the
> code
> > from kernel 5.15 or whatever will be the next LTS kernel. I haven't
> > started yet.
> >
> > DSA:
> > We will migrate some more boards to DSA, the lantiq/xrx200
> target is
> > using DSA in master now. It looks like some boards with qca8k would
> > switch. These changes should be local to one target or even board
> > anyway. The infrastructure is already provided. This can continue
> > without much coordination and we can see what is finished when
> we branch.
> >
> > firewall4:
> > OpenWrt master contains firewall4 optionally which uses nftables
> > instead of iptables. It uses the same configuration as
> firewall3, the
> > old configuration should still work. Custom iptables extensions
> should
> > also still work when we use iptables-nft which supports the
> iptables
> > user interface and generates nftables rules, even Debian stable
> uses
> > iptables-nft by default. Flow offloading (software and hardware) is
> > supported by upstream kernel when nftables is used, we are
> currently
> > using a patch to make it "work" with iptables too.
> >
> > We have to activate it by default and deactivate firewall3.
> > We probably need some minor modifications to LuCi to show the
> current
> > nftables firewall status. This is not device depended like DSA,
> we can
> > easily test this on one device and it should work the same way
> on all
> > others.
> >
> > LuCi:
> > What is still needed in LuCi?
> >
> >
> > Is there anything else which is blocking, should be added or
> needs a
> > discussion?
> >
> > Hauke
> >
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> <mailto:openwrt-devel at lists.openwrt.org>
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> <https://lists.openwrt.org/mailman/listinfo/openwrt-devel>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> <mailto:openwrt-devel at lists.openwrt.org>
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> <https://lists.openwrt.org/mailman/listinfo/openwrt-devel>
>
More information about the openwrt-devel
mailing list