On Sat, 22 Jan 2022 09:38:01 +0000 Rui Salvaterra <rsalvate...@gmail.com> wrote:
> Hi, Ansuel, > > On Sat, 22 Jan 2022 at 01:08, Ansuel Smith <ansuels...@gmail.com> wrote: > > > > > > So.. how should we proceed with this? From what I understand the idea is to > > merge this ASAP. > > But not a moment sooner. ;) I'm sure we agree that this patch won't be > merged upstream in its current form, according to the comments > received, and the less we diverge from upstream, the better for > maintenance. > > > Think we have to change this with the DSA specific attribute. > > Ok, let's step back and take a look at our possibilities. Stephen > Hemminger suggested auditing all kernel usage of IFLA_LINK and adding > checks where needed to make sure the current users don't break [1]. > This would certainly work, but that would mean sprinkling error checks > in possibly quite a number of places [2]. Vladimir Oltean, instead, > suggested creating a new netlink attribute for this specific purpose > [3] (let's call it IFLA_CPU, for example). I believe the latter is the > less intrusive of the options, with the added bonus of not having to > overload IFLA_LINK with different semantics (something I personally > dislike). I would also rename "link" to "cpu" in the ip patch > (avoiding the overload, once again). > > [1] https://lore.kernel.org/netdev/20210411100411.6d16e51d@hermes.local/ > [2] https://elixir.bootlin.com/linux/latest/A/ident/IFLA_LINK > [3] https://lore.kernel.org/netdev/20210411170939.cxmva5vdcpqu4bmi@skbuf/ Hello guys, I am pessimistic about this being resolved soon in upstream, so my suggestion to you for OpenWRT is to do something that can be used now, for example a sysfs attribute, and create an utility for changing port's CPU port. Then if things get solved in upstream, you can just change the utility's code. Marek _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
