On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet <sebast...@lorquet.fr> wrote:
> Hello,
>
> Nathan proposal to have a kconfig, with a default to the historical
> algorithm, is a good solution.
>
Kconfig will work if you mean this:
int16_t crc16(FAR const uint8_t *src, size_t len)
{
#if defined(CONFIG_CRC16_IBM)
return crc16ibmpart(src, len, 0);
#elif defined(CONFIG_CRC16_XMODEM)
return crc16xmodempart(src, len, 0);
#endif
}
I have my doubts that you actually read the original change on GH.
This is (a summary of) what was pushed:
int16_t crc16(FAR const uint8_t *src, size_t len)
{
return crc16ibmpart(src, len, 0);
}
>
> I Maintain, DO NOT CHANGE THE DEFAULT CRC ROUTINE.
>
No. The open source project provides the ability for proprietary forks to
override the master branch default with the company default. Your approach
stalls the development process. A trivial change like this should not take
a week to commit.
If Kconfig is in place it is now 100% your company's responsibility to
maintain your desired CRC defaults in your private proprietary board files.
Any change to the master will not affect you in this case. Keep
CONFIG_CRC16_XMODEM in your shipping product's config and ignore what
anchao is doing. An open source project's ability to innovate should not be
held up by your preferences.
> CRCs are relied upon for data structure integrity validation.
>
> If you change the default, new code will consider valid data record as
> invalid and STUFF IN PRODUCTION WILL BREAK
>
No it won't. I just told you why above.
