Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations

On 5/11/24 7:01 AM, Warner Losh wrote:
> On Sat, May 11, 2024, 3:19 AM Konstantin Belousov <[email protected]>
> wrote:
> 
>> On Sat, May 11, 2024 at 01:38:38AM +0200, [email protected] wrote:
>>> In my opinion, if all goes well, it may be wise to remove the old code
>> in the next major version. Could do the full list, or just FreeBSD 4 and 5
>> compatibility, for instance. Barring notable negative feedback, of course.
>>
>> Strongly disagree.  You are breaking ABI compat for users, for what gain?
>>
>> I do not care about disabling options in GENERIC (but then they must appear
>> in LINT).
>>
> 
> 
> This sums up my view as well. Fine to not be in GENERIC, but removal is a
> bridge too far.

Same here.

However, what I haven't really seen anywhere in this thread is a clear
articulation for _why_ to remove these options for GENERIC.  The reasons I
can think of for removing from GENERIC are:

1) Shrinking the size of .text in GENERIC.  GENERIC is not MINIMAL, but it
    is also not KITCHENSINK.  While there is some binary-only software around
    that requires older versions, I strongly suspect that it is a rare use
    case and requiring a custom kernel is not too large of an imposition on
    users who need that.

2) Reducing the attack surface available via system calls (which is what
    COMPAT_FREEBSD<n> is mostly about).  I suspect that the theoretical
    surface here is larger than the practical one, but it's not zero.

If there are in fact binary-only programs built against older releases that
are widely used, then that might be a counter balance to the range of
options removed from GENERIC.

I think though that just removing from GENERIC does not mean we should axe
the ports.  misc/compatN need to stick around for the options to still work
in a custom kernel, and they are very cheap to build (just tarring up
binaries).  Also, converting COMPAT_FREEBSD<n> to modules is non-trivial.

-- 
John Baldwin