Re: git: a85dcd4ac4b0 - main - netlink: restrict default userland switch to netlink to i386/amd64.

> On 26 Mar 2023, at 18:08, Warner Losh <imp@bsdimp.com> wrote:
> 
> 
> 
> On Sun, Mar 26, 2023, 6:45 PM Jessica Clarke <jrtc27@freebsd.org> wrote:
> On 26 Mar 2023, at 17:17, Ed Maste <emaste@freebsd.org> wrote:
>> 
>> 
>> On Sun, 26 Mar 2023 at 07:07, Alexander V. Chernikov
>> <melifaro@freebsd.org> wrote:
>>> 
>>> The branch main has been updated by melifaro:
>>> 
>>> URL: https://cgit.FreeBSD.org/src/commit/?id=a85dcd4ac4b0612b63b5a71eeaaa707a09ae0003
>>> 
>>> commit a85dcd4ac4b0612b63b5a71eeaaa707a09ae0003
>>> Author:     Alexander V. Chernikov <melifaro@FreeBSD.org>
>>> AuthorDate: 2023-03-26 11:05:21 +0000
>>> Commit:     Alexander V. Chernikov <melifaro@FreeBSD.org>
>>> CommitDate: 2023-03-26 11:06:53 +0000
>>> 
>>>   netlink: restrict default userland switch to netlink to i386/amd64.
>> 
>> We should keep default options the same for all Tier-1 architectures,
>> so amd64 and arm64 should be in sync.
> 
> But also, what’s the technical justification for this change? There
> should not be gratuitous differences between architectures like this,
> only when there is a reason something shouldn’t be enabled. Why should
> x86 (and possibly arm64) get netlink, but not arm/powerpc/riscv? We
> have very few machine-dependent defaults in src.opts.mk. If there is no
> such justification then please revert this in its entirety, and if
> there is such a justification it belongs in a comment above the if.
> 
> So if it's a matter of testing, enable it everywhere. We'll get testing. If it's something known to be bad on say riscv64 we should have a bug and reference it in src.opts.mk to document why. If it's just a conservative approach to a roll out, then I'd suggest being less conservative. 

I’d actually be happy to enable it everywhere and fix the bugs if/when they appear.
I’m not sure what is the best way to implement this. Having Netlink on in the userland implies that route(8) (and soon ifconfig(8)) will need kernel-side Netlink support to operate.
Thus, for the particular platform, one need to ensure that either (a) Netlink is present in the config or (b) Netlink is loaded as a module during boot. Given that successful boot w/o working route(8) may not just happen, it really boils down to (a).
arm (like v6) or ppc or riscv may represent some lower-scale devices, where adding Netlink to the default config may represent a size (or other) concerns [1]. 

With all that in mind, in order to gather more datapoints & have a gradual conversion, I started with the archs I can reason about. In the end, it’s pretty easy to enable it arch-by-arch (or everywhere) when there is a consensus on the situation mentioned above.


[1] https://reviews.freebsd.org/D39047

> 
> Warner