Re: [RESEND PATCH net-next 1/4] net: hsr: generate supervision frame without HSR tag

[Vladimir Oltean <olteanv@gmail.com>]

On Tue, Feb 02, 2021 at 08:49:25AM -0600, George McCollister wrote:
> > > This part is not intuitive and I don't have a copy of the documents
> > > where v0 was defined. It's unfortunate this code even supports v0
> > > because AFAIK no one else uses it; but it's in here so we have to keep
> > > supporting it I guess.
> > > In v1 the tag has an eth type of 0x892f and the encapsulated
> > > supervisory frame has a type of 0x88fb. In v0 0x88fb is used for the
> > > eth type and there is no encapsulation type. So... this is correct
> > > however I compared supervisory frame generation before and after this
> > > patch for v0 and I found a problem. My changes make it add 0x88fb
> > > again later for v0 which it's not supposed to do. I'll have to fix
> > > that part somehow.
> >
> > Step 1: Sign up for HSR maintainership, it's currently orphan
> > Step 2: Delete HSRv0 support
> > Step 3: See if anyone shouts, probably not
> > Step 4: Profit.
> 
> not a bad idea however user space defaults to using v0 when doing:
> ip link add name hsr0 type hsr slave1 eth0 slave2 eth1
> 
> To use v1 you need to append "version 1".
> 
> It seems like it might be a hard sell to break the userspace default
> even if no one in their right mind is using it. Still think it's
> possible?

While HSRv0 is the default, IFLA_HSR_VERSION won't be put in the netlink
message generated by iproute2 unless you explicitly write "version 0".
So it's not like ip-link will now error out on a default RTM_NEWLINK
message, the kernel will just use a different (and more sane, according
to you) default.
Removing support for a protocol is pretty radical, but I guess if you
can make a convincing argument that nobody depends on it, it may get
accepted.