Re: [PATCH v2] config.mak.uname: update settings for FreeBSD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Carlo Arenas <carenas@xxxxxxxxx> writes:

> On Thu, Jun 12, 2025 at 12:36:46AM -0800, Brad Smith wrote:
>>
>> FreeBSD 6.0 has memmem().
>
> but AFAIK it was buggy, uncompatible with the "standard" and
> didn't perform that well, at least until FreeBSD 12.

Declaring that we will not support anything older than 12, which was
from Dec 2018, feels a bit too harsh, so conditional to check if we
are at or above 12 is needed instead?

Documentation/technical/platform-support.adoc is probably a good
place to start a discussion.

 * It spells out Minimum Requirements which includes C99 at the
   minimum, which in turn disqualifies really ancient ones and ones
   perhaps before FreeBSD 7 (which had GCC 4)?

 * It also requires the platform has active security support.  If I
   trust https://www.freebsd.org/security/#sup page, it means
   anything older than 13.4-RELEASE are EoL already.

 * The document has a space at the end that is intended to list
   contacts for ports on platforms, but currently it is not very
   actively used.  Should we extend it to include various flavours
   of BSDs and other systems, and start listing the minimum
   supported versions as well?

Stepping back a bit, do we already have some mechanism to say "hey
you seem to be on FreeBSD but you are at release N that is way older
than the minimum version X we support" and stop the build?  If we
do, we should tell that mechanism about our decision in a patch like
this.

If we don't, I wonder if we want to have such a mechanism?  I am
personally undecided.  It would help those "casual" users and
builders who do not get their hands dirty at all (aka "I'll build
only from the official release tarballs") if we did so when they try
to build on something we know will not work well, especially if it
is kept up to date relative to what the platform-support document
lists.  But at the same time, those who do not mind fixing and
extending to make it work on out-of-support systems will be
inconvenienced with one more roadblock to dismantle before
proceeding.

Thoughts?




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux