> On 26 Mar 2023, at 18:08, Warner Losh <[email protected]> wrote:
>
>
>
> On Sun, Mar 26, 2023, 6:45 PM Jessica Clarke <[email protected]> wrote:
> On 26 Mar 2023, at 17:17, Ed Maste <[email protected]> wrote:
>>
>>
>> On Sun, 26 Mar 2023 at 07:07, Alexander V. Chernikov
>> <[email protected]> wrote:
>>>
>>> The branch main has been updated by melifaro:
>>>
>>> URL:
>>> https://cgit.FreeBSD.org/src/commit/?id=a85dcd4ac4b0612b63b5a71eeaaa707a09ae0003
>>>
>>> commit a85dcd4ac4b0612b63b5a71eeaaa707a09ae0003
>>> Author: Alexander V. Chernikov <[email protected]>
>>> AuthorDate: 2023-03-26 11:05:21 +0000
>>> Commit: Alexander V. Chernikov <[email protected]>
>>> 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
