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.
