You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by chao an <ma...@gmail.com> on 2025/04/07 08:35:21 UTC
Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Hi Community,
I plan to switch the default CRC16 algorithm directory of NuttX from
CRC-16/XMODEM to CRC-16/IBM:
https://github.com/apache/nuttx/pull/16147
CRC-16/XMODEM as the default implementation has significant limitations,
especially when communicating with popular operating systems and it comes
to CRC encryption verification, the algorithm needs to be switched.
I have conducted research on POSIX-compatible operating systems, and almost
all of them use CRC-16/IBM as the default implementation:
OpenBSD:
https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
FreeBSD:
https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
Linux:
https://github.com/torvalds/linux/blob/master/lib/crc16.c
So I need your vote here:
If you prefer CRC-16/XMODEM, please reply with -1.
If you recommend CRC-16/IBM, please reply with +1.
BRs,
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
Look for yourself. For the past few years all my NuttX commits are bug
fixes.
You are talking to the wrong guy.
On Wed, 9 Apr 2025 at 12:39, Sebastien Lorquet <se...@lorquet.fr> wrote:
> There was no diatribe this time. I had the same single argument the
> whole time: for long term self compatibility, we can not change the
> behaviour of existing critical code. That's what matter.
>
> We just added the complete deletion idea later.
>
> The addition of new, well specified CRC routines is very valuable. But
> it does not distract me from the modification of the existing routine.
>
>
> I will never stop fighting for innocent users that don't post on this ml
> and will get silently broken code behind their back. That is a priority
> over contributor satisfaction to see PRs merged.
>
> This is definitely a political (or policy) reason. Another name for this
> is "project management".
>
> We cant just throw any code we like in a large shared project. We're not
> just coding for ourselves at this point.
>
>
> Sebastien
>
>
> On 09/04/2025 17:58, Lwazi Dube wrote:
> > Too late. If I am reading the PR correctly, he has changed the subject
> and
> > we are back to the original default.
> >
> > uint16_t crc16(FAR const uint8_t *src, size_t len)
> > {
> > return crc16xmodempart(src, len, 0);
> > }
> >
> > He fought for a couple of days before giving up. I don't blame him. This
> > suggestion, which is good, should have come at the beginning. The
> preceding
> > diatribe didn't help.
> >
> > On Wed, 9 Apr 2025 at 10:15, Alan C. Assis <ac...@gmail.com> wrote:
> >
> >> Agree! This will end this discussion! And it will make it clear what
> >> algorithm was used.
> >>
> >> BR,
> >>
> >> Alan
> >>
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
There was no diatribe this time. I had the same single argument the
whole time: for long term self compatibility, we can not change the
behaviour of existing critical code. That's what matter.
We just added the complete deletion idea later.
The addition of new, well specified CRC routines is very valuable. But
it does not distract me from the modification of the existing routine.
I will never stop fighting for innocent users that don't post on this ml
and will get silently broken code behind their back. That is a priority
over contributor satisfaction to see PRs merged.
This is definitely a political (or policy) reason. Another name for this
is "project management".
We cant just throw any code we like in a large shared project. We're not
just coding for ourselves at this point.
Sebastien
On 09/04/2025 17:58, Lwazi Dube wrote:
> Too late. If I am reading the PR correctly, he has changed the subject and
> we are back to the original default.
>
> uint16_t crc16(FAR const uint8_t *src, size_t len)
> {
> return crc16xmodempart(src, len, 0);
> }
>
> He fought for a couple of days before giving up. I don't blame him. This
> suggestion, which is good, should have come at the beginning. The preceding
> diatribe didn't help.
>
> On Wed, 9 Apr 2025 at 10:15, Alan C. Assis <ac...@gmail.com> wrote:
>
>> Agree! This will end this discussion! And it will make it clear what
>> algorithm was used.
>>
>> BR,
>>
>> Alan
>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Nathan Hartman <ha...@gmail.com>.
This proposal looks reasonable to me. Also a few people disagreed with my
earlier Kconfig idea and this proposal avoids introducing such a Kconfig,
so I think it's an improvement. I'm +1 to this idea.
On Wed, Apr 9, 2025 at 9:08 AM Sebastien Lorquet <se...@lorquet.fr>
wrote:
> Yes.
>
> This function was not carefully specified, we just have to acknowledge
> that. it was a past mistake, but now it's here, and we need to support it
> in a stable way.
>
> About that function, the only thing to do is to properly document what it
> actually does, and keep it that way. There is no reason to change the
> behaviour.
>
>
> At one point, this badly specified function could be deprecated, before
> being removed in a later release.
>
> It is easy to add deprecation warnings and recommendations not to use with
> alternative api indications.
>
>
> Here is a proposal for a timeline
>
> -now:
>
> * document that crc16 is deprecated and will be removed. do not change its
> behaviour.
>
> * add code and accurate documentation for any well specified crc16
> function that is required, based on a common implementation or not, not
> important. it's just optimization at this point.
>
> -later:
>
> * remove the legacy crc16
>
> * do the same for any other crc function like crc32 if available.
>
>
> What does the community think about that ?
>
>
> Sebastien
>
>
> On 09/04/2025 14:05, Nathan Hartman wrote:
>
> I think the real problem here is that the function is called crc16() with
> no details about which CRC polynomial is used. Maybe it's better not to
> have this function at all and to have *only* functions with names like
> crc16ibm() or crc16ccitt(). Then it is much more clear what CRC is being
> called in other code and there will be no risk of breaking compatibility in
> the future.
>
> On Wed, Apr 9, 2025 at 5:44 AM chao an <ma...@gmail.com> wrote:
>
>> Seriously, I have no interest in crc16 at all, and I don't think your 15
>> years of experience in cryptography deserves my respect.
>> These are all old technologies. I just want to help people who have
>> problems in Nuttx.
>> I also hope that every time someone asks about the implementation of
>> crc16, you can reply to them as soon as possible instead of hiding behind
>> emails.
>>
>> I won't reply to any messages from you anymore, I wish you all the best,
>> thanks.
>>
>> BRs,
>>
>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 17:17写道：
>>
>>> Why are you so unwilling to change your opinion?
>>>
>>> You are ready to break nuttx just for your comfort, in whatever way it
>>> may take to advance your own agenda. That is very political.
>>>
>>> I dont like that.
>>>
>>> We need a consensus, and a majority of this thread is against the change
>>> you want to make. So it should be cancelled.
>>>
>>> Rememeber this thread is a vote. My vote is No. Close the pull request.
>>> Do another one that has chances to be consensually accepted. Let's vote
>>> again.
>>>
>>>
>>> I will paste the quote that Greg posted in the thread about the modlib
>>> change:
>>>
>>>
>>> Rules for voting are a little different for code changes.
>>>
>>> The required Apache voting process is here: https://www.apache.org/foundation/voting.html
>>>
>>> For code changes, that document says: "Votes on code modifications follow consensus approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval> <https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this scenario, a negative vote constitutes a veto<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto>, which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus> declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it."
>>> And "For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto> and kill the proposal dead until all vetoers withdraw their -1 votes.
>>> Unless the proposer declares that the vote is using lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes are required for a code-modification proposal to pass."
>>>
>>>
>>>
>>>
>>> Sebastien
>>>
>>>
>>> On 09/04/2025 10:20, chao an wrote:
>>>
>>> I like your second option, so could we remove the implementation of both
>>> crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
>>>
>>> BRs,
>>>
>>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 16:00写道：
>>>
>>>> Hello,
>>>>
>>>> once again, the number of usage is unimportant and irrelevant.
>>>>
>>>> The ONLY thing that matters is that when I call function POOP, it
>>>> always does POOP. Not something else.
>>>>
>>>> Because users you are unaware of expect this function to do POOP and
>>>> they may not be able to change their code.
>>>>
>>>> If you want different crc functions, use something else.
>>>>
>>>>
>>>> A better example than the building: the zip format
>>>>
>>>> zip uses adler32 which is not even a proper crc and is largely
>>>> suboptimal.
>>>>
>>>> zip developers NEVER changed this in decades, even if they know it's
>>>> bad. Why? because otherwise, old zip files would become completely unusable.
>>>>
>>>> We have the same issue.
>>>>
>>>> The default crc is bad? OK, deal with it. Add better functions.
>>>> Document everywhere that the default crc is deprecated and should not be
>>>> used because more accurate functions are available.
>>>>
>>>> But dont change the damn thing.
>>>>
>>>> I am against changing the default implementation of the legacy function
>>>> silently.
>>>>
>>>> I would be less mad if you REMOVED the old function rather than
>>>> silently changing its behaviour. (that would still be bad, however)
>>>>
>>>> Sebastien
>>>>
>>>>
>>>> On 09/04/2025 05:12, chao an wrote:
>>>>
>>>> I can empathize. But we just don't want to fill this regret again in
>>>> the new building.
>>>> The lack of standards is currently the biggest issue hindering the
>>>> promotion of this proposal.
>>>> Another interesting thing, I'd like to share another data from github:
>>>> if we search for the lookup table of crc16 on GitHub, you'll find that
>>>> CRC-16/IBM with a higher use rate:
>>>>
>>>> CRC-16/IBM: 3.1k
>>>>
>>>> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
>>>> [image: image.png]
>>>>
>>>> CRC-16/XMODEM: 304
>>>>
>>>> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
>>>>
>>>> [image: image.png]
>>>>
>>>> BRs,
>>>>
>>>> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
>>>>
>>>>> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
>>>>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com>
>>>>> wrote:
>>>>> > > > > An open source project's ability to innovate should not be
>>>>> > > > > held up by your preferences.
>>>>> > > >
>>>>> > > > The last sentence is completely wrong. Its not about
>>>>> "preference" but
>>>>> > > > impacting self-compatibility and long term maintenance. Messing
>>>>> the
>>>>> > > > foundations and defaults is not innovation. Try building a home
>>>>> when
>>>>> > > > the project constantly changes during the process, when you have
>>>>> 10
>>>>> > > > floors ready and suddenly you need to change pavements.
>>>>> Innovation is
>>>>> > > > when you create new functionality and give users a choice without
>>>>> > > > breaking existing working stuff.
>>>>> >
>>>>> > So you think it's more important to maintain your current 10 floors
>>>>> > building, and it's none of your business if a 100 floors skyscraper
>>>>> appears
>>>>> > in the future? so could you afford all the developer time spent on
>>>>> this
>>>>> > kind of problem?
>>>>>
>>>>> Anchao, what I meant was to finish 10 floor building as planned
>>>>> (development), let people live inside that building (maintenance), and
>>>>> move development resources to 100 floor building as planned, without
>>>>> changing plans in the middle of construction, not getting stuck on 10
>>>>> floor building construction because plans change all the time and
>>>>> never getting to that 100 floor building. Its good to have solid
>>>>> immutable tools that you can depend on. Imagine there are devices
>>>>> already deployed out there that may not be possible to update, yes
>>>>> maintenance (in terms of keeping them inter-operational) may be the
>>>>> priority in that case, because replacing all devices may wipe out the
>>>>> company and leave owner with ubearable financial debt.
>>>>>
>>>>> I know this CRC is an important and quite hard problem, and I hope
>>>>> there can be a win-win solution where users have choice when they need
>>>>> one, thank you for bringing this up to the attention.. to be honest I
>>>>> have no clue what is the best solution here if there is no standard to
>>>>> relay on :-)
>>>>>
>>>>> --
>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>>>
>>>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Yes.
This function was not carefully specified, we just have to acknowledge
that. it was a past mistake, but now it's here, and we need to support
it in a stable way.
About that function, the only thing to do is to properly document what
it actually does, and keep it that way. There is no reason to change the
behaviour.
At one point, this badly specified function could be deprecated, before
being removed in a later release.
It is easy to add deprecation warnings and recommendations not to use
with alternative api indications.
Here is a proposal for a timeline
-now:
* document that crc16 is deprecated and will be removed. do not change
its behaviour.
* add code and accurate documentation for any well specified crc16
function that is required, based on a common implementation or not, not
important. it's just optimization at this point.
-later:
* remove the legacy crc16
* do the same for any other crc function like crc32 if available.
What does the community think about that ?
Sebastien
On 09/04/2025 14:05, Nathan Hartman wrote:
> I think the real problem here is that the function is called crc16()
> with no details about which CRC polynomial is used. Maybe it's better
> not to have this function at all and to have *only* functions with
> names like crc16ibm() or crc16ccitt(). Then it is much more clear what
> CRC is being called in other code and there will be no risk of
> breaking compatibility in the future.
>
> On Wed, Apr 9, 2025 at 5:44 AM chao an <ma...@gmail.com> wrote:
>
> Seriously, I have no interest in crc16 at all, and I don't think
> your 15 years of experience in cryptography deserves my respect.
> These are all old technologies. I just want to help people who
> have problems in Nuttx.
> I also hope that every time someone asks about the implementation
> of crc16, you can reply to them as soon as possible instead of
> hiding behind emails.
>
> I won't reply to any messages from you anymore, I wish you all the
> best, thanks.
>
> BRs,
>
> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三
> 17:17写道：
>
> Why are you so unwilling to change your opinion?
>
> You are ready to break nuttx just for your comfort, in
> whatever way it may take to advance your own agenda. That is
> very political.
>
> I dont like that.
>
> We need a consensus, and a majority of this thread is against
> the change you want to make. So it should be cancelled.
>
> Rememeber this thread is a vote. My vote is No. Close the pull
> request. Do another one that has chances to be consensually
> accepted. Let's vote again.
>
>
> I will paste the quote that Greg posted in the thread about
> the modlib change:
>
>
> Rules for voting are a little different for code changes.
>
> The required Apache voting process is here:https://www.apache.org/foundation/voting.html
>
> For code changes, that document says: "Votes on code modifications follow consensus approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval> <https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this scenario, a negative vote constitutes a veto<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto>, which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus> declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it."
> And "For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto> and kill the proposal dead until all vetoers withdraw their -1 votes.
> Unless the proposer declares that the vote is using lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes are required for a code-modification proposal to pass."
>
>
>
> Sebastien
>
>
> On 09/04/2025 10:20, chao an wrote:
>> I like your second option, so could we remove the
>> implementation of both crc16/crc16part interfaces and rename
>> to crc16xmodem/crc16xmodempart?
>>
>> BRs,
>>
>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三
>> 16:00写道：
>>
>> Hello,
>>
>> once again, the number of usage is unimportant and
>> irrelevant.
>>
>> The ONLY thing that matters is that when I call function
>> POOP, it always does POOP. Not something else.
>>
>> Because users you are unaware of expect this function to
>> do POOP and they may not be able to change their code.
>>
>> If you want different crc functions, use something else.
>>
>>
>> A better example than the building: the zip format
>>
>> zip uses adler32 which is not even a proper crc and is
>> largely suboptimal.
>>
>> zip developers NEVER changed this in decades, even if
>> they know it's bad. Why? because otherwise, old zip files
>> would become completely unusable.
>>
>> We have the same issue.
>>
>> The default crc is bad? OK, deal with it. Add better
>> functions. Document everywhere that the default crc is
>> deprecated and should not be used because more accurate
>> functions are available.
>>
>> But dont change the damn thing.
>>
>> I am against changing the default implementation of the
>> legacy function silently.
>>
>> I would be less mad if you REMOVED the old function
>> rather than silently changing its behaviour. (that would
>> still be bad, however)
>>
>> Sebastien
>>
>>
>> On 09/04/2025 05:12, chao an wrote:
>>> I can empathize. But we just don't want to fill this
>>> regret again in the new building.
>>> The lack of standards is currently the biggest issue
>>> hindering the promotion of this proposal.
>>> Another interesting thing, I'd like to share another
>>> data from github:
>>> if we search for the lookup table of crc16 on GitHub,
>>> you'll find that CRC-16/IBM with a higher use rate:
>>>
>>> CRC-16/IBM: 3.1k
>>> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
>>> <https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code>
>>>
>>> image.png
>>>
>>> CRC-16/XMODEM: 304
>>> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
>>> <https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code>
>>>
>>> image.png
>>>
>>> BRs,
>>>
>>> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三
>>> 10:52写道：
>>>
>>> On Wed, Apr 9, 2025 at 3:45 AM chao an
>>> <ma...@gmail.com> wrote:
>>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube
>>> <lw...@gmail.com> wrote:
>>> > > > > An open source project's ability to innovate
>>> should not be
>>> > > > > held up by your preferences.
>>> > > >
>>> > > > The last sentence is completely wrong. Its not
>>> about "preference" but
>>> > > > impacting self-compatibility and long term
>>> maintenance. Messing the
>>> > > > foundations and defaults is not innovation.
>>> Try building a home when
>>> > > > the project constantly changes during the
>>> process, when you have 10
>>> > > > floors ready and suddenly you need to change
>>> pavements. Innovation is
>>> > > > when you create new functionality and give
>>> users a choice without
>>> > > > breaking existing working stuff.
>>> >
>>> > So you think it's more important to maintain your
>>> current 10 floors
>>> > building, and it's none of your business if a 100
>>> floors skyscraper appears
>>> > in the future? so could you afford all the
>>> developer time spent on this
>>> > kind of problem?
>>>
>>> Anchao, what I meant was to finish 10 floor building
>>> as planned
>>> (development), let people live inside that building
>>> (maintenance), and
>>> move development resources to 100 floor building as
>>> planned, without
>>> changing plans in the middle of construction, not
>>> getting stuck on 10
>>> floor building construction because plans change all
>>> the time and
>>> never getting to that 100 floor building. Its good
>>> to have solid
>>> immutable tools that you can depend on. Imagine
>>> there are devices
>>> already deployed out there that may not be possible
>>> to update, yes
>>> maintenance (in terms of keeping them
>>> inter-operational) may be the
>>> priority in that case, because replacing all devices
>>> may wipe out the
>>> company and leave owner with ubearable financial debt.
>>>
>>> I know this CRC is an important and quite hard
>>> problem, and I hope
>>> there can be a win-win solution where users have
>>> choice when they need
>>> one, thank you for bringing this up to the
>>> attention.. to be honest I
>>> have no clue what is the best solution here if there
>>> is no standard to
>>> relay on :-)
>>>
>>> --
>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Tomek CEDRO <to...@cedro.info>.
Alllright, I have created a dedicated issue "[13.0] CRC cleanup" on
GitHub, with summary of conclusions from this discussion, please
verify and update where necessary:
https://github.com/apache/nuttx/issues/16174
This is also pinned in the project view under 13.0 release (gathering ideas):
https://github.com/orgs/apache/projects/455/views/1
* There is no common CRC standard that we can rely upon.
* Looks like we need dedicated implementations of various crc[16/32]
algorithms that would be separated and recognizable by name.
* We are not changing any defaults until next major release (13.0).
* We will try to select algorithm that would provide best possible
compatibility with other OS (i.e. Linux), and change defaults only in
places outside core that impacts interoperability, but keep defaults
untouched in places that may impact self-compatibility.
* Implementations should be distinguishable by function name,
developer may select which one to use, but core components should not
use Kconfig like selection as this will impact self-compatibility.
Thank you all for the valuable discussion, ideas and suggestions!! :-)
Tomek
ps/2: Anchao if the time is up for vote please close the vote with
voting results, thank you :-)
On Wed, Apr 9, 2025 at 4:16 PM Alan C. Assis <ac...@gmail.com> wrote:
>
> Agree! This will end this discussion! And it will make it clear what algorithm was used.
>
> BR,
>
> Alan
>
> On Wed, Apr 9, 2025 at 9:07 AM Nathan Hartman <ha...@gmail.com> wrote:
>>
>> I think the real problem here is that the function is called crc16() with no details about which CRC polynomial is used. Maybe it's better not to have this function at all and to have *only* functions with names like crc16ibm() or crc16ccitt(). Then it is much more clear what CRC is being called in other code and there will be no risk of breaking compatibility in the future.
>>
>> On Wed, Apr 9, 2025 at 5:44 AM chao an <ma...@gmail.com> wrote:
>>>
>>> Seriously, I have no interest in crc16 at all, and I don't think your 15 years of experience in cryptography deserves my respect.
>>> These are all old technologies. I just want to help people who have problems in Nuttx.
>>> I also hope that every time someone asks about the implementation of crc16, you can reply to them as soon as possible instead of hiding behind emails.
>>>
>>> I won't reply to any messages from you anymore, I wish you all the best, thanks.
>>>
>>> BRs,
>>>
>>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 17:17写道：
>>>>
>>>> Why are you so unwilling to change your opinion?
>>>>
>>>> You are ready to break nuttx just for your comfort, in whatever way it may take to advance your own agenda. That is very political.
>>>>
>>>> I dont like that.
>>>>
>>>> We need a consensus, and a majority of this thread is against the change you want to make. So it should be cancelled.
>>>>
>>>> Rememeber this thread is a vote. My vote is No. Close the pull request. Do another one that has chances to be consensually accepted. Let's vote again.
>>>>
>>>>
>>>> I will paste the quote that Greg posted in the thread about the modlib change:
>>>>
>>>>
>>>> Rules for voting are a little different for code changes.
>>>>
>>>> The required Apache voting process is here: https://www.apache.org/foundation/voting.html
>>>>
>>>> For code changes, that document says: "Votes on code modifications follow consensus approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this scenario, a negative vote constitutes a veto<https://www.apache.org/foundation/voting.html#Veto>, which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it."
>>>> And "For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> and kill the proposal dead until all vetoers withdraw their -1 votes.
>>>> Unless the proposer declares that the vote is using lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes are required for a code-modification proposal to pass."
>>>>
>>>>
>>>>
>>>> Sebastien
>>>>
>>>>
>>>> On 09/04/2025 10:20, chao an wrote:
>>>>
>>>> I like your second option, so could we remove the implementation of both crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
>>>>
>>>> BRs,
>>>>
>>>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 16:00写道：
>>>>>
>>>>> Hello,
>>>>>
>>>>> once again, the number of usage is unimportant and irrelevant.
>>>>>
>>>>> The ONLY thing that matters is that when I call function POOP, it always does POOP. Not something else.
>>>>>
>>>>> Because users you are unaware of expect this function to do POOP and they may not be able to change their code.
>>>>>
>>>>> If you want different crc functions, use something else.
>>>>>
>>>>>
>>>>> A better example than the building: the zip format
>>>>>
>>>>> zip uses adler32 which is not even a proper crc and is largely suboptimal.
>>>>>
>>>>> zip developers NEVER changed this in decades, even if they know it's bad. Why? because otherwise, old zip files would become completely unusable.
>>>>>
>>>>> We have the same issue.
>>>>>
>>>>> The default crc is bad? OK, deal with it. Add better functions. Document everywhere that the default crc is deprecated and should not be used because more accurate functions are available.
>>>>>
>>>>> But dont change the damn thing.
>>>>>
>>>>> I am against changing the default implementation of the legacy function silently.
>>>>>
>>>>> I would be less mad if you REMOVED the old function rather than silently changing its behaviour. (that would still be bad, however)
>>>>>
>>>>> Sebastien
>>>>>
>>>>>
>>>>> On 09/04/2025 05:12, chao an wrote:
>>>>>
>>>>> I can empathize. But we just don't want to fill this regret again in the new building.
>>>>> The lack of standards is currently the biggest issue hindering the promotion of this proposal.
>>>>> Another interesting thing, I'd like to share another data from github:
>>>>> if we search for the lookup table of crc16 on GitHub, you'll find that CRC-16/IBM with a higher use rate:
>>>>>
>>>>> CRC-16/IBM: 3.1k
>>>>> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
>>>>>
>>>>>
>>>>> CRC-16/XMODEM: 304
>>>>> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
>>>>>
>>>>>
>>>>>
>>>>> BRs,
>>>>>
>>>>> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
>>>>>>
>>>>>> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
>>>>>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com> wrote:
>>>>>> > > > > An open source project's ability to innovate should not be
>>>>>> > > > > held up by your preferences.
>>>>>> > > >
>>>>>> > > > The last sentence is completely wrong. Its not about "preference" but
>>>>>> > > > impacting self-compatibility and long term maintenance. Messing the
>>>>>> > > > foundations and defaults is not innovation. Try building a home when
>>>>>> > > > the project constantly changes during the process, when you have 10
>>>>>> > > > floors ready and suddenly you need to change pavements. Innovation is
>>>>>> > > > when you create new functionality and give users a choice without
>>>>>> > > > breaking existing working stuff.
>>>>>> >
>>>>>> > So you think it's more important to maintain your current 10 floors
>>>>>> > building, and it's none of your business if a 100 floors skyscraper appears
>>>>>> > in the future? so could you afford all the developer time spent on this
>>>>>> > kind of problem?
>>>>>>
>>>>>> Anchao, what I meant was to finish 10 floor building as planned
>>>>>> (development), let people live inside that building (maintenance), and
>>>>>> move development resources to 100 floor building as planned, without
>>>>>> changing plans in the middle of construction, not getting stuck on 10
>>>>>> floor building construction because plans change all the time and
>>>>>> never getting to that 100 floor building. Its good to have solid
>>>>>> immutable tools that you can depend on. Imagine there are devices
>>>>>> already deployed out there that may not be possible to update, yes
>>>>>> maintenance (in terms of keeping them inter-operational) may be the
>>>>>> priority in that case, because replacing all devices may wipe out the
>>>>>> company and leave owner with ubearable financial debt.
>>>>>>
>>>>>> I know this CRC is an important and quite hard problem, and I hope
>>>>>> there can be a win-win solution where users have choice when they need
>>>>>> one, thank you for bringing this up to the attention.. to be honest I
>>>>>> have no clue what is the best solution here if there is no standard to
>>>>>> relay on :-)
>>>>>>
>>>>>> --
>>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
Too late. If I am reading the PR correctly, he has changed the subject and
we are back to the original default.
uint16_t crc16(FAR const uint8_t *src, size_t len)
{
return crc16xmodempart(src, len, 0);
}
He fought for a couple of days before giving up. I don't blame him. This
suggestion, which is good, should have come at the beginning. The preceding
diatribe didn't help.
On Wed, 9 Apr 2025 at 10:15, Alan C. Assis <ac...@gmail.com> wrote:
> Agree! This will end this discussion! And it will make it clear what
> algorithm was used.
>
> BR,
>
> Alan
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by "Alan C. Assis" <ac...@gmail.com>.
Agree! This will end this discussion! And it will make it clear what
algorithm was used.
BR,
Alan
On Wed, Apr 9, 2025 at 9:07 AM Nathan Hartman <ha...@gmail.com>
wrote:
> I think the real problem here is that the function is called crc16() with
> no details about which CRC polynomial is used. Maybe it's better not to
> have this function at all and to have *only* functions with names like
> crc16ibm() or crc16ccitt(). Then it is much more clear what CRC is being
> called in other code and there will be no risk of breaking compatibility in
> the future.
>
> On Wed, Apr 9, 2025 at 5:44 AM chao an <ma...@gmail.com> wrote:
>
>> Seriously, I have no interest in crc16 at all, and I don't think your 15
>> years of experience in cryptography deserves my respect.
>> These are all old technologies. I just want to help people who have
>> problems in Nuttx.
>> I also hope that every time someone asks about the implementation of
>> crc16, you can reply to them as soon as possible instead of hiding behind
>> emails.
>>
>> I won't reply to any messages from you anymore, I wish you all the best,
>> thanks.
>>
>> BRs,
>>
>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 17:17写道：
>>
>>> Why are you so unwilling to change your opinion?
>>>
>>> You are ready to break nuttx just for your comfort, in whatever way it
>>> may take to advance your own agenda. That is very political.
>>>
>>> I dont like that.
>>>
>>> We need a consensus, and a majority of this thread is against the change
>>> you want to make. So it should be cancelled.
>>>
>>> Rememeber this thread is a vote. My vote is No. Close the pull request.
>>> Do another one that has chances to be consensually accepted. Let's vote
>>> again.
>>>
>>>
>>> I will paste the quote that Greg posted in the thread about the modlib
>>> change:
>>>
>>>
>>> Rules for voting are a little different for code changes.
>>>
>>> The required Apache voting process is here: https://www.apache.org/foundation/voting.html
>>>
>>> For code changes, that document says: "Votes on code modifications follow consensus approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval> <https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this scenario, a negative vote constitutes a veto<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto>, which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus> declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it."
>>> And "For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto> and kill the proposal dead until all vetoers withdraw their -1 votes.
>>> Unless the proposer declares that the vote is using lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes are required for a code-modification proposal to pass."
>>>
>>>
>>>
>>>
>>> Sebastien
>>>
>>>
>>> On 09/04/2025 10:20, chao an wrote:
>>>
>>> I like your second option, so could we remove the implementation of both
>>> crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
>>>
>>> BRs,
>>>
>>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 16:00写道：
>>>
>>>> Hello,
>>>>
>>>> once again, the number of usage is unimportant and irrelevant.
>>>>
>>>> The ONLY thing that matters is that when I call function POOP, it
>>>> always does POOP. Not something else.
>>>>
>>>> Because users you are unaware of expect this function to do POOP and
>>>> they may not be able to change their code.
>>>>
>>>> If you want different crc functions, use something else.
>>>>
>>>>
>>>> A better example than the building: the zip format
>>>>
>>>> zip uses adler32 which is not even a proper crc and is largely
>>>> suboptimal.
>>>>
>>>> zip developers NEVER changed this in decades, even if they know it's
>>>> bad. Why? because otherwise, old zip files would become completely unusable.
>>>>
>>>> We have the same issue.
>>>>
>>>> The default crc is bad? OK, deal with it. Add better functions.
>>>> Document everywhere that the default crc is deprecated and should not be
>>>> used because more accurate functions are available.
>>>>
>>>> But dont change the damn thing.
>>>>
>>>> I am against changing the default implementation of the legacy function
>>>> silently.
>>>>
>>>> I would be less mad if you REMOVED the old function rather than
>>>> silently changing its behaviour. (that would still be bad, however)
>>>>
>>>> Sebastien
>>>>
>>>>
>>>> On 09/04/2025 05:12, chao an wrote:
>>>>
>>>> I can empathize. But we just don't want to fill this regret again in
>>>> the new building.
>>>> The lack of standards is currently the biggest issue hindering the
>>>> promotion of this proposal.
>>>> Another interesting thing, I'd like to share another data from github:
>>>> if we search for the lookup table of crc16 on GitHub, you'll find that
>>>> CRC-16/IBM with a higher use rate:
>>>>
>>>> CRC-16/IBM: 3.1k
>>>>
>>>> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
>>>> [image: image.png]
>>>>
>>>> CRC-16/XMODEM: 304
>>>>
>>>> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
>>>>
>>>> [image: image.png]
>>>>
>>>> BRs,
>>>>
>>>> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
>>>>
>>>>> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
>>>>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com>
>>>>> wrote:
>>>>> > > > > An open source project's ability to innovate should not be
>>>>> > > > > held up by your preferences.
>>>>> > > >
>>>>> > > > The last sentence is completely wrong. Its not about
>>>>> "preference" but
>>>>> > > > impacting self-compatibility and long term maintenance. Messing
>>>>> the
>>>>> > > > foundations and defaults is not innovation. Try building a home
>>>>> when
>>>>> > > > the project constantly changes during the process, when you have
>>>>> 10
>>>>> > > > floors ready and suddenly you need to change pavements.
>>>>> Innovation is
>>>>> > > > when you create new functionality and give users a choice without
>>>>> > > > breaking existing working stuff.
>>>>> >
>>>>> > So you think it's more important to maintain your current 10 floors
>>>>> > building, and it's none of your business if a 100 floors skyscraper
>>>>> appears
>>>>> > in the future? so could you afford all the developer time spent on
>>>>> this
>>>>> > kind of problem?
>>>>>
>>>>> Anchao, what I meant was to finish 10 floor building as planned
>>>>> (development), let people live inside that building (maintenance), and
>>>>> move development resources to 100 floor building as planned, without
>>>>> changing plans in the middle of construction, not getting stuck on 10
>>>>> floor building construction because plans change all the time and
>>>>> never getting to that 100 floor building. Its good to have solid
>>>>> immutable tools that you can depend on. Imagine there are devices
>>>>> already deployed out there that may not be possible to update, yes
>>>>> maintenance (in terms of keeping them inter-operational) may be the
>>>>> priority in that case, because replacing all devices may wipe out the
>>>>> company and leave owner with ubearable financial debt.
>>>>>
>>>>> I know this CRC is an important and quite hard problem, and I hope
>>>>> there can be a win-win solution where users have choice when they need
>>>>> one, thank you for bringing this up to the attention.. to be honest I
>>>>> have no clue what is the best solution here if there is no standard to
>>>>> relay on :-)
>>>>>
>>>>> --
>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>>>
>>>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Nathan Hartman <ha...@gmail.com>.
I think the real problem here is that the function is called crc16() with
no details about which CRC polynomial is used. Maybe it's better not to
have this function at all and to have *only* functions with names like
crc16ibm() or crc16ccitt(). Then it is much more clear what CRC is being
called in other code and there will be no risk of breaking compatibility in
the future.
On Wed, Apr 9, 2025 at 5:44 AM chao an <ma...@gmail.com> wrote:
> Seriously, I have no interest in crc16 at all, and I don't think your 15
> years of experience in cryptography deserves my respect.
> These are all old technologies. I just want to help people who have
> problems in Nuttx.
> I also hope that every time someone asks about the implementation of
> crc16, you can reply to them as soon as possible instead of hiding behind
> emails.
>
> I won't reply to any messages from you anymore, I wish you all the best,
> thanks.
>
> BRs,
>
> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 17:17写道：
>
>> Why are you so unwilling to change your opinion?
>>
>> You are ready to break nuttx just for your comfort, in whatever way it
>> may take to advance your own agenda. That is very political.
>>
>> I dont like that.
>>
>> We need a consensus, and a majority of this thread is against the change
>> you want to make. So it should be cancelled.
>>
>> Rememeber this thread is a vote. My vote is No. Close the pull request.
>> Do another one that has chances to be consensually accepted. Let's vote
>> again.
>>
>>
>> I will paste the quote that Greg posted in the thread about the modlib
>> change:
>>
>>
>> Rules for voting are a little different for code changes.
>>
>> The required Apache voting process is here: https://www.apache.org/foundation/voting.html
>>
>> For code changes, that document says: "Votes on code modifications follow consensus approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval> <https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this scenario, a negative vote constitutes a veto<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto>, which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus> declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it."
>> And "For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto> and kill the proposal dead until all vetoers withdraw their -1 votes.
>> Unless the proposer declares that the vote is using lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes are required for a code-modification proposal to pass."
>>
>>
>>
>>
>> Sebastien
>>
>>
>> On 09/04/2025 10:20, chao an wrote:
>>
>> I like your second option, so could we remove the implementation of both
>> crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
>>
>> BRs,
>>
>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 16:00写道：
>>
>>> Hello,
>>>
>>> once again, the number of usage is unimportant and irrelevant.
>>>
>>> The ONLY thing that matters is that when I call function POOP, it always
>>> does POOP. Not something else.
>>>
>>> Because users you are unaware of expect this function to do POOP and
>>> they may not be able to change their code.
>>>
>>> If you want different crc functions, use something else.
>>>
>>>
>>> A better example than the building: the zip format
>>>
>>> zip uses adler32 which is not even a proper crc and is largely
>>> suboptimal.
>>>
>>> zip developers NEVER changed this in decades, even if they know it's
>>> bad. Why? because otherwise, old zip files would become completely unusable.
>>>
>>> We have the same issue.
>>>
>>> The default crc is bad? OK, deal with it. Add better functions. Document
>>> everywhere that the default crc is deprecated and should not be used
>>> because more accurate functions are available.
>>>
>>> But dont change the damn thing.
>>>
>>> I am against changing the default implementation of the legacy function
>>> silently.
>>>
>>> I would be less mad if you REMOVED the old function rather than silently
>>> changing its behaviour. (that would still be bad, however)
>>>
>>> Sebastien
>>>
>>>
>>> On 09/04/2025 05:12, chao an wrote:
>>>
>>> I can empathize. But we just don't want to fill this regret again in the
>>> new building.
>>> The lack of standards is currently the biggest issue hindering the
>>> promotion of this proposal.
>>> Another interesting thing, I'd like to share another data from github:
>>> if we search for the lookup table of crc16 on GitHub, you'll find that
>>> CRC-16/IBM with a higher use rate:
>>>
>>> CRC-16/IBM: 3.1k
>>>
>>> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
>>> [image: image.png]
>>>
>>> CRC-16/XMODEM: 304
>>>
>>> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
>>>
>>> [image: image.png]
>>>
>>> BRs,
>>>
>>> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
>>>
>>>> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
>>>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com>
>>>> wrote:
>>>> > > > > An open source project's ability to innovate should not be
>>>> > > > > held up by your preferences.
>>>> > > >
>>>> > > > The last sentence is completely wrong. Its not about "preference"
>>>> but
>>>> > > > impacting self-compatibility and long term maintenance. Messing
>>>> the
>>>> > > > foundations and defaults is not innovation. Try building a home
>>>> when
>>>> > > > the project constantly changes during the process, when you have
>>>> 10
>>>> > > > floors ready and suddenly you need to change pavements.
>>>> Innovation is
>>>> > > > when you create new functionality and give users a choice without
>>>> > > > breaking existing working stuff.
>>>> >
>>>> > So you think it's more important to maintain your current 10 floors
>>>> > building, and it's none of your business if a 100 floors skyscraper
>>>> appears
>>>> > in the future? so could you afford all the developer time spent on
>>>> this
>>>> > kind of problem?
>>>>
>>>> Anchao, what I meant was to finish 10 floor building as planned
>>>> (development), let people live inside that building (maintenance), and
>>>> move development resources to 100 floor building as planned, without
>>>> changing plans in the middle of construction, not getting stuck on 10
>>>> floor building construction because plans change all the time and
>>>> never getting to that 100 floor building. Its good to have solid
>>>> immutable tools that you can depend on. Imagine there are devices
>>>> already deployed out there that may not be possible to update, yes
>>>> maintenance (in terms of keeping them inter-operational) may be the
>>>> priority in that case, because replacing all devices may wipe out the
>>>> company and leave owner with ubearable financial debt.
>>>>
>>>> I know this CRC is an important and quite hard problem, and I hope
>>>> there can be a win-win solution where users have choice when they need
>>>> one, thank you for bringing this up to the attention.. to be honest I
>>>> have no clue what is the best solution here if there is no standard to
>>>> relay on :-)
>>>>
>>>> --
>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>>
>>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by chao an <ma...@gmail.com>.
Seriously, I have no interest in crc16 at all, and I don't think your 15
years of experience in cryptography deserves my respect.
These are all old technologies. I just want to help people who have
problems in Nuttx.
I also hope that every time someone asks about the implementation of crc16,
you can reply to them as soon as possible instead of hiding behind emails.
I won't reply to any messages from you anymore, I wish you all the best,
thanks.
BRs,
Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 17:17写道：
> Why are you so unwilling to change your opinion?
>
> You are ready to break nuttx just for your comfort, in whatever way it may
> take to advance your own agenda. That is very political.
>
> I dont like that.
>
> We need a consensus, and a majority of this thread is against the change
> you want to make. So it should be cancelled.
>
> Rememeber this thread is a vote. My vote is No. Close the pull request. Do
> another one that has chances to be consensually accepted. Let's vote again.
>
>
> I will paste the quote that Greg posted in the thread about the modlib
> change:
>
>
> Rules for voting are a little different for code changes.
>
> The required Apache voting process is here: https://www.apache.org/foundation/voting.html
>
> For code changes, that document says: "Votes on code modifications follow consensus approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval> <https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this scenario, a negative vote constitutes a veto<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto>, which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus> declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it."
> And "For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> <https://www.apache.org/foundation/voting.html#Veto> and kill the proposal dead until all vetoers withdraw their -1 votes.
> Unless the proposer declares that the vote is using lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> <https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes are required for a code-modification proposal to pass."
>
>
>
>
> Sebastien
>
>
> On 09/04/2025 10:20, chao an wrote:
>
> I like your second option, so could we remove the implementation of both
> crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
>
> BRs,
>
> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 16:00写道：
>
>> Hello,
>>
>> once again, the number of usage is unimportant and irrelevant.
>>
>> The ONLY thing that matters is that when I call function POOP, it always
>> does POOP. Not something else.
>>
>> Because users you are unaware of expect this function to do POOP and they
>> may not be able to change their code.
>>
>> If you want different crc functions, use something else.
>>
>>
>> A better example than the building: the zip format
>>
>> zip uses adler32 which is not even a proper crc and is largely suboptimal.
>>
>> zip developers NEVER changed this in decades, even if they know it's bad.
>> Why? because otherwise, old zip files would become completely unusable.
>>
>> We have the same issue.
>>
>> The default crc is bad? OK, deal with it. Add better functions. Document
>> everywhere that the default crc is deprecated and should not be used
>> because more accurate functions are available.
>>
>> But dont change the damn thing.
>>
>> I am against changing the default implementation of the legacy function
>> silently.
>>
>> I would be less mad if you REMOVED the old function rather than silently
>> changing its behaviour. (that would still be bad, however)
>>
>> Sebastien
>>
>>
>> On 09/04/2025 05:12, chao an wrote:
>>
>> I can empathize. But we just don't want to fill this regret again in the
>> new building.
>> The lack of standards is currently the biggest issue hindering the
>> promotion of this proposal.
>> Another interesting thing, I'd like to share another data from github:
>> if we search for the lookup table of crc16 on GitHub, you'll find that
>> CRC-16/IBM with a higher use rate:
>>
>> CRC-16/IBM: 3.1k
>>
>> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
>> [image: image.png]
>>
>> CRC-16/XMODEM: 304
>>
>> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
>>
>> [image: image.png]
>>
>> BRs,
>>
>> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
>>
>>> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
>>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com>
>>> wrote:
>>> > > > > An open source project's ability to innovate should not be
>>> > > > > held up by your preferences.
>>> > > >
>>> > > > The last sentence is completely wrong. Its not about "preference"
>>> but
>>> > > > impacting self-compatibility and long term maintenance. Messing the
>>> > > > foundations and defaults is not innovation. Try building a home
>>> when
>>> > > > the project constantly changes during the process, when you have 10
>>> > > > floors ready and suddenly you need to change pavements. Innovation
>>> is
>>> > > > when you create new functionality and give users a choice without
>>> > > > breaking existing working stuff.
>>> >
>>> > So you think it's more important to maintain your current 10 floors
>>> > building, and it's none of your business if a 100 floors skyscraper
>>> appears
>>> > in the future? so could you afford all the developer time spent on this
>>> > kind of problem?
>>>
>>> Anchao, what I meant was to finish 10 floor building as planned
>>> (development), let people live inside that building (maintenance), and
>>> move development resources to 100 floor building as planned, without
>>> changing plans in the middle of construction, not getting stuck on 10
>>> floor building construction because plans change all the time and
>>> never getting to that 100 floor building. Its good to have solid
>>> immutable tools that you can depend on. Imagine there are devices
>>> already deployed out there that may not be possible to update, yes
>>> maintenance (in terms of keeping them inter-operational) may be the
>>> priority in that case, because replacing all devices may wipe out the
>>> company and leave owner with ubearable financial debt.
>>>
>>> I know this CRC is an important and quite hard problem, and I hope
>>> there can be a win-win solution where users have choice when they need
>>> one, thank you for bringing this up to the attention.. to be honest I
>>> have no clue what is the best solution here if there is no standard to
>>> relay on :-)
>>>
>>> --
>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>
>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Why are you so unwilling to change your opinion?
You are ready to break nuttx just for your comfort, in whatever way it
may take to advance your own agenda. That is very political.
I dont like that.
We need a consensus, and a majority of this thread is against the change
you want to make. So it should be cancelled.
Rememeber this thread is a vote. My vote is No. Close the pull request.
Do another one that has chances to be consensually accepted. Let's vote
again.
I will paste the quote that Greg posted in the thread about the modlib
change:
Rules for voting are a little different for code changes.
The required Apache voting process is here:https://www.apache.org/foundation/voting.html
For code changes, that document says: "Votes on code modifications follow consensus approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this scenario, a negative vote constitutes a veto<https://www.apache.org/foundation/voting.html#Veto>, which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it."
And "For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos<https://www.apache.org/foundation/voting.html#Veto> and kill the proposal dead until all vetoers withdraw their -1 votes.
Unless the proposer declares that the vote is using lazy consensus<https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes are required for a code-modification proposal to pass."
Sebastien
On 09/04/2025 10:20, chao an wrote:
> I like your second option, so could we remove the implementation of
> both crc16/crc16part interfaces and rename to
> crc16xmodem/crc16xmodempart?
>
> BRs,
>
> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 16:00写道：
>
> Hello,
>
> once again, the number of usage is unimportant and irrelevant.
>
> The ONLY thing that matters is that when I call function POOP, it
> always does POOP. Not something else.
>
> Because users you are unaware of expect this function to do POOP
> and they may not be able to change their code.
>
> If you want different crc functions, use something else.
>
>
> A better example than the building: the zip format
>
> zip uses adler32 which is not even a proper crc and is largely
> suboptimal.
>
> zip developers NEVER changed this in decades, even if they know
> it's bad. Why? because otherwise, old zip files would become
> completely unusable.
>
> We have the same issue.
>
> The default crc is bad? OK, deal with it. Add better functions.
> Document everywhere that the default crc is deprecated and should
> not be used because more accurate functions are available.
>
> But dont change the damn thing.
>
> I am against changing the default implementation of the legacy
> function silently.
>
> I would be less mad if you REMOVED the old function rather than
> silently changing its behaviour. (that would still be bad, however)
>
> Sebastien
>
>
> On 09/04/2025 05:12, chao an wrote:
>> I can empathize. But we just don't want to fill this regret again
>> in the new building.
>> The lack of standards is currently the biggest issue hindering
>> the promotion of this proposal.
>> Another interesting thing, I'd like to share another data from
>> github:
>> if we search for the lookup table of crc16 on GitHub, you'll find
>> that CRC-16/IBM with a higher use rate:
>>
>> CRC-16/IBM: 3.1k
>> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
>> <https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code>
>>
>> image.png
>>
>> CRC-16/XMODEM: 304
>> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
>> <https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code>
>>
>> image.png
>>
>> BRs,
>>
>> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
>>
>> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com>
>> wrote:
>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube
>> <lw...@gmail.com> wrote:
>> > > > > An open source project's ability to innovate should
>> not be
>> > > > > held up by your preferences.
>> > > >
>> > > > The last sentence is completely wrong. Its not about
>> "preference" but
>> > > > impacting self-compatibility and long term maintenance.
>> Messing the
>> > > > foundations and defaults is not innovation. Try
>> building a home when
>> > > > the project constantly changes during the process, when
>> you have 10
>> > > > floors ready and suddenly you need to change pavements.
>> Innovation is
>> > > > when you create new functionality and give users a
>> choice without
>> > > > breaking existing working stuff.
>> >
>> > So you think it's more important to maintain your current
>> 10 floors
>> > building, and it's none of your business if a 100 floors
>> skyscraper appears
>> > in the future? so could you afford all the developer time
>> spent on this
>> > kind of problem?
>>
>> Anchao, what I meant was to finish 10 floor building as planned
>> (development), let people live inside that building
>> (maintenance), and
>> move development resources to 100 floor building as planned,
>> without
>> changing plans in the middle of construction, not getting
>> stuck on 10
>> floor building construction because plans change all the time and
>> never getting to that 100 floor building. Its good to have solid
>> immutable tools that you can depend on. Imagine there are devices
>> already deployed out there that may not be possible to
>> update, yes
>> maintenance (in terms of keeping them inter-operational) may
>> be the
>> priority in that case, because replacing all devices may wipe
>> out the
>> company and leave owner with ubearable financial debt.
>>
>> I know this CRC is an important and quite hard problem, and I
>> hope
>> there can be a win-win solution where users have choice when
>> they need
>> one, thank you for bringing this up to the attention.. to be
>> honest I
>> have no clue what is the best solution here if there is no
>> standard to
>> relay on :-)
>>
>> --
>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by chao an <ma...@gmail.com>.
I like your second option, so could we remove the implementation of both
crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
BRs,
Sebastien Lorquet <se...@lorquet.fr> 于2025年4月9日周三 16:00写道：
> Hello,
>
> once again, the number of usage is unimportant and irrelevant.
>
> The ONLY thing that matters is that when I call function POOP, it always
> does POOP. Not something else.
>
> Because users you are unaware of expect this function to do POOP and they
> may not be able to change their code.
>
> If you want different crc functions, use something else.
>
>
> A better example than the building: the zip format
>
> zip uses adler32 which is not even a proper crc and is largely suboptimal.
>
> zip developers NEVER changed this in decades, even if they know it's bad.
> Why? because otherwise, old zip files would become completely unusable.
>
> We have the same issue.
>
> The default crc is bad? OK, deal with it. Add better functions. Document
> everywhere that the default crc is deprecated and should not be used
> because more accurate functions are available.
>
> But dont change the damn thing.
>
> I am against changing the default implementation of the legacy function
> silently.
>
> I would be less mad if you REMOVED the old function rather than silently
> changing its behaviour. (that would still be bad, however)
>
> Sebastien
>
>
> On 09/04/2025 05:12, chao an wrote:
>
> I can empathize. But we just don't want to fill this regret again in the
> new building.
> The lack of standards is currently the biggest issue hindering the
> promotion of this proposal.
> Another interesting thing, I'd like to share another data from github:
> if we search for the lookup table of crc16 on GitHub, you'll find that
> CRC-16/IBM with a higher use rate:
>
> CRC-16/IBM: 3.1k
>
> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
> [image: image.png]
>
> CRC-16/XMODEM: 304
>
> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
>
> [image: image.png]
>
> BRs,
>
> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
>
>> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com>
>> wrote:
>> > > > > An open source project's ability to innovate should not be
>> > > > > held up by your preferences.
>> > > >
>> > > > The last sentence is completely wrong. Its not about "preference"
>> but
>> > > > impacting self-compatibility and long term maintenance. Messing the
>> > > > foundations and defaults is not innovation. Try building a home when
>> > > > the project constantly changes during the process, when you have 10
>> > > > floors ready and suddenly you need to change pavements. Innovation
>> is
>> > > > when you create new functionality and give users a choice without
>> > > > breaking existing working stuff.
>> >
>> > So you think it's more important to maintain your current 10 floors
>> > building, and it's none of your business if a 100 floors skyscraper
>> appears
>> > in the future? so could you afford all the developer time spent on this
>> > kind of problem?
>>
>> Anchao, what I meant was to finish 10 floor building as planned
>> (development), let people live inside that building (maintenance), and
>> move development resources to 100 floor building as planned, without
>> changing plans in the middle of construction, not getting stuck on 10
>> floor building construction because plans change all the time and
>> never getting to that 100 floor building. Its good to have solid
>> immutable tools that you can depend on. Imagine there are devices
>> already deployed out there that may not be possible to update, yes
>> maintenance (in terms of keeping them inter-operational) may be the
>> priority in that case, because replacing all devices may wipe out the
>> company and leave owner with ubearable financial debt.
>>
>> I know this CRC is an important and quite hard problem, and I hope
>> there can be a win-win solution where users have choice when they need
>> one, thank you for bringing this up to the attention.. to be honest I
>> have no clue what is the best solution here if there is no standard to
>> relay on :-)
>>
>> --
>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
once again, the number of usage is unimportant and irrelevant.
The ONLY thing that matters is that when I call function POOP, it always
does POOP. Not something else.
Because users you are unaware of expect this function to do POOP and
they may not be able to change their code.
If you want different crc functions, use something else.
A better example than the building: the zip format
zip uses adler32 which is not even a proper crc and is largely suboptimal.
zip developers NEVER changed this in decades, even if they know it's
bad. Why? because otherwise, old zip files would become completely unusable.
We have the same issue.
The default crc is bad? OK, deal with it. Add better functions. Document
everywhere that the default crc is deprecated and should not be used
because more accurate functions are available.
But dont change the damn thing.
I am against changing the default implementation of the legacy function
silently.
I would be less mad if you REMOVED the old function rather than silently
changing its behaviour. (that would still be bad, however)
Sebastien
On 09/04/2025 05:12, chao an wrote:
> I can empathize. But we just don't want to fill this regret again in
> the new building.
> The lack of standards is currently the biggest issue hindering the
> promotion of this proposal.
> Another interesting thing, I'd like to share another data from github:
> if we search for the lookup table of crc16 on GitHub, you'll find that
> CRC-16/IBM with a higher use rate:
>
> CRC-16/IBM: 3.1k
> https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
> <https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code>
>
> image.png
>
> CRC-16/XMODEM: 304
> https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
> <https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code>
>
> image.png
>
> BRs,
>
> Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
>
> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube
> <lw...@gmail.com> wrote:
> > > > > An open source project's ability to innovate should not be
> > > > > held up by your preferences.
> > > >
> > > > The last sentence is completely wrong. Its not about
> "preference" but
> > > > impacting self-compatibility and long term maintenance.
> Messing the
> > > > foundations and defaults is not innovation. Try building a
> home when
> > > > the project constantly changes during the process, when you
> have 10
> > > > floors ready and suddenly you need to change pavements.
> Innovation is
> > > > when you create new functionality and give users a choice
> without
> > > > breaking existing working stuff.
> >
> > So you think it's more important to maintain your current 10 floors
> > building, and it's none of your business if a 100 floors
> skyscraper appears
> > in the future? so could you afford all the developer time spent
> on this
> > kind of problem?
>
> Anchao, what I meant was to finish 10 floor building as planned
> (development), let people live inside that building (maintenance), and
> move development resources to 100 floor building as planned, without
> changing plans in the middle of construction, not getting stuck on 10
> floor building construction because plans change all the time and
> never getting to that 100 floor building. Its good to have solid
> immutable tools that you can depend on. Imagine there are devices
> already deployed out there that may not be possible to update, yes
> maintenance (in terms of keeping them inter-operational) may be the
> priority in that case, because replacing all devices may wipe out the
> company and leave owner with ubearable financial debt.
>
> I know this CRC is an important and quite hard problem, and I hope
> there can be a win-win solution where users have choice when they need
> one, thank you for bringing this up to the attention.. to be honest I
> have no clue what is the best solution here if there is no standard to
> relay on :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Xiang Xiao <xi...@gmail.com>.
I am neutral to map crc16 to crc16ibmpart unconditionally, but against
changing the map by Kconfig.
On Wed, Apr 9, 2025 at 9:56 AM chao an <ma...@gmail.com> wrote:
> I want to reach a consensus with everyone
> We have spent too much time explaining similar issues to different
> developers. we can see that @Alan has wanted to promote this for a long
> time. As Lwazi said, the discussion in the community is for code and future
> directions, not for politics.
>
> If the experts who voted against can agree to this proposal, we will not
> spend time explaining to future developers why the current code
> implementation is different from the popular operating system, but only
> need to explain to developers who have already used Nuttx that we are close
> to the mainstream solution, which makes compatibility better. I think they
> will understand the community's decision.
>
> Every time there are questions about CRC compatibility, only Alan and
> Xiaoxiang are answering everyone's questions. Where are the voices of you
> opponents?
>
> https://github.com/apache/nuttx/issues/14532
>
>
> BRs,
>
> Lwazi Dube <lw...@gmail.com> 于2025年4月9日周三 03:32写道：
>
> > There was some false information in his comments but I am here for the
> code
> > not the politics.
> >
> > Are you -1 on @anchao's original vote?
> >
> > On Tue, 8 Apr 2025 at 14:54, Peter Barada <pe...@gmail.com>
> wrote:
> >
> > > +1 regarding Tomek's comments.
> > >
> > > I'm all for documenting the current semantics of CRCs used by Nuttx and
> > > expanding function names where they match well known standard CRCs, but
> > > any effort to change(or worse make configurable) the semantics of CRCs
> > > as currently used in Nuttx leads to a world of hurt...
> > >
> > > I think that a CRC API that keeps things self-compatible, doesn't
> > > sacrifice performance/footprint, and allows for underlying HW
> > > implementation would be a good thing(tm). :-)
> > >
> > > On 4/8/25 13:58, Tomek CEDRO wrote:
> > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com> wrote:
> > > >> 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.
> > > > I don't agree with this approach. Some defaults were set in NuttX and
> > > > these defaults assure self-compatibility in various components that
> we
> > > > should treat as sacred because people depend on it. Maintenance cost
> > > > is nowadays higher than development cost unfortunately. We cannot
> > > > change whatever we like whenever we like and blame users that their
> > > > stuff stops working because of our upstream changes. There are
> > > > commercial and industrial products running on NuttX and we should
> keep
> > > > that in mind.
> > > >
> > > > Its not about how quickly we can change things, but how to add new
> > > > features as an option/alternative without destroying existing working
> > > > stuff.
> > > >
> > > > NuttX is like a foundation, it should be solid, so many things can be
> > > > built on top of it. We should not change the foundations, not allow
> > > > building different things at the same time in the same place which is
> > > > impossible. We should offer a choice, not enforce changes.
> > > >
> > > > Linux may not be the best "reference" as it tends to change so often
> > > > many people abandoned it as serious solution. Its a maintenance
> > > > nightmare or single-use solution if you don't care what is inside.
> > > > Unfortunately Linux is most popular so most software and drivers are
> > > > written initially for Linux that propagates problems to all related
> OS
> > > > (i.e. FreeBSD drm/kms video drivers), we try to avoid that in NuttX.
> > > > Even Rust was not able to cope with Linux's internal changes pace, so
> > > > they abandoned in-kernel maintenance and started writing from scratch
> > > > RedoxOS in pure Rust, which seems to be long but reasonable path -
> > > > people will have choice whether use Linux or switch to Redox, maybe
> in
> > > > the long run Redox wins because of long term self-compatibility. Also
> > > > in NuttX we have Rust port that does not impact all users, only
> > > > interested folks can enable Rust if they want it, no one else is
> > > > impacted, users have choice. I am sure the same approach can be
> > > > applied to CRC stuff :-)
> > > >
> > > >
> > > >> 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.
> > > > The last sentence is completely wrong. Its not about "preference" but
> > > > impacting self-compatibility and long term maintenance. Messing the
> > > > foundations and defaults is not innovation. Try building a home when
> > > > the project constantly changes during the process, when you have 10
> > > > floors ready and suddenly you need to change pavements. Innovation is
> > > > when you create new functionality and give users a choice without
> > > > breaking existing working stuff.
> > > >
> > > >
> > > > Back to the point, this discussion touched important area, lets focus
> > > > on how to design a versatile CRC(16/32) API that would keep things
> > > > operational and self-compatible, but create a new user selectable
> > > > choices/alternatives. That seems the best constructive way forward
> :-)
> > > >
> > > > Thanks! :-)
> > > > Tomek
> > > >
> > > --
> > > Peter Barada
> > > peter.barada@gmail.com
> > >
> > >
> >
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by chao an <ma...@gmail.com>.
I want to reach a consensus with everyone
We have spent too much time explaining similar issues to different
developers. we can see that @Alan has wanted to promote this for a long
time. As Lwazi said, the discussion in the community is for code and future
directions, not for politics.
If the experts who voted against can agree to this proposal, we will not
spend time explaining to future developers why the current code
implementation is different from the popular operating system, but only
need to explain to developers who have already used Nuttx that we are close
to the mainstream solution, which makes compatibility better. I think they
will understand the community's decision.
Every time there are questions about CRC compatibility, only Alan and
Xiaoxiang are answering everyone's questions. Where are the voices of you
opponents?
https://github.com/apache/nuttx/issues/14532
BRs,
Lwazi Dube <lw...@gmail.com> 于2025年4月9日周三 03:32写道：
> There was some false information in his comments but I am here for the code
> not the politics.
>
> Are you -1 on @anchao's original vote?
>
> On Tue, 8 Apr 2025 at 14:54, Peter Barada <pe...@gmail.com> wrote:
>
> > +1 regarding Tomek's comments.
> >
> > I'm all for documenting the current semantics of CRCs used by Nuttx and
> > expanding function names where they match well known standard CRCs, but
> > any effort to change(or worse make configurable) the semantics of CRCs
> > as currently used in Nuttx leads to a world of hurt...
> >
> > I think that a CRC API that keeps things self-compatible, doesn't
> > sacrifice performance/footprint, and allows for underlying HW
> > implementation would be a good thing(tm). :-)
> >
> > On 4/8/25 13:58, Tomek CEDRO wrote:
> > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com> wrote:
> > >> 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.
> > > I don't agree with this approach. Some defaults were set in NuttX and
> > > these defaults assure self-compatibility in various components that we
> > > should treat as sacred because people depend on it. Maintenance cost
> > > is nowadays higher than development cost unfortunately. We cannot
> > > change whatever we like whenever we like and blame users that their
> > > stuff stops working because of our upstream changes. There are
> > > commercial and industrial products running on NuttX and we should keep
> > > that in mind.
> > >
> > > Its not about how quickly we can change things, but how to add new
> > > features as an option/alternative without destroying existing working
> > > stuff.
> > >
> > > NuttX is like a foundation, it should be solid, so many things can be
> > > built on top of it. We should not change the foundations, not allow
> > > building different things at the same time in the same place which is
> > > impossible. We should offer a choice, not enforce changes.
> > >
> > > Linux may not be the best "reference" as it tends to change so often
> > > many people abandoned it as serious solution. Its a maintenance
> > > nightmare or single-use solution if you don't care what is inside.
> > > Unfortunately Linux is most popular so most software and drivers are
> > > written initially for Linux that propagates problems to all related OS
> > > (i.e. FreeBSD drm/kms video drivers), we try to avoid that in NuttX.
> > > Even Rust was not able to cope with Linux's internal changes pace, so
> > > they abandoned in-kernel maintenance and started writing from scratch
> > > RedoxOS in pure Rust, which seems to be long but reasonable path -
> > > people will have choice whether use Linux or switch to Redox, maybe in
> > > the long run Redox wins because of long term self-compatibility. Also
> > > in NuttX we have Rust port that does not impact all users, only
> > > interested folks can enable Rust if they want it, no one else is
> > > impacted, users have choice. I am sure the same approach can be
> > > applied to CRC stuff :-)
> > >
> > >
> > >> 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.
> > > The last sentence is completely wrong. Its not about "preference" but
> > > impacting self-compatibility and long term maintenance. Messing the
> > > foundations and defaults is not innovation. Try building a home when
> > > the project constantly changes during the process, when you have 10
> > > floors ready and suddenly you need to change pavements. Innovation is
> > > when you create new functionality and give users a choice without
> > > breaking existing working stuff.
> > >
> > >
> > > Back to the point, this discussion touched important area, lets focus
> > > on how to design a versatile CRC(16/32) API that would keep things
> > > operational and self-compatible, but create a new user selectable
> > > choices/alternatives. That seems the best constructive way forward :-)
> > >
> > > Thanks! :-)
> > > Tomek
> > >
> > --
> > Peter Barada
> > peter.barada@gmail.com
> >
> >
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
There was some false information in his comments but I am here for the code
not the politics.
Are you -1 on @anchao's original vote?
On Tue, 8 Apr 2025 at 14:54, Peter Barada <pe...@gmail.com> wrote:
> +1 regarding Tomek's comments.
>
> I'm all for documenting the current semantics of CRCs used by Nuttx and
> expanding function names where they match well known standard CRCs, but
> any effort to change(or worse make configurable) the semantics of CRCs
> as currently used in Nuttx leads to a world of hurt...
>
> I think that a CRC API that keeps things self-compatible, doesn't
> sacrifice performance/footprint, and allows for underlying HW
> implementation would be a good thing(tm). :-)
>
> On 4/8/25 13:58, Tomek CEDRO wrote:
> > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com> wrote:
> >> 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.
> > I don't agree with this approach. Some defaults were set in NuttX and
> > these defaults assure self-compatibility in various components that we
> > should treat as sacred because people depend on it. Maintenance cost
> > is nowadays higher than development cost unfortunately. We cannot
> > change whatever we like whenever we like and blame users that their
> > stuff stops working because of our upstream changes. There are
> > commercial and industrial products running on NuttX and we should keep
> > that in mind.
> >
> > Its not about how quickly we can change things, but how to add new
> > features as an option/alternative without destroying existing working
> > stuff.
> >
> > NuttX is like a foundation, it should be solid, so many things can be
> > built on top of it. We should not change the foundations, not allow
> > building different things at the same time in the same place which is
> > impossible. We should offer a choice, not enforce changes.
> >
> > Linux may not be the best "reference" as it tends to change so often
> > many people abandoned it as serious solution. Its a maintenance
> > nightmare or single-use solution if you don't care what is inside.
> > Unfortunately Linux is most popular so most software and drivers are
> > written initially for Linux that propagates problems to all related OS
> > (i.e. FreeBSD drm/kms video drivers), we try to avoid that in NuttX.
> > Even Rust was not able to cope with Linux's internal changes pace, so
> > they abandoned in-kernel maintenance and started writing from scratch
> > RedoxOS in pure Rust, which seems to be long but reasonable path -
> > people will have choice whether use Linux or switch to Redox, maybe in
> > the long run Redox wins because of long term self-compatibility. Also
> > in NuttX we have Rust port that does not impact all users, only
> > interested folks can enable Rust if they want it, no one else is
> > impacted, users have choice. I am sure the same approach can be
> > applied to CRC stuff :-)
> >
> >
> >> 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.
> > The last sentence is completely wrong. Its not about "preference" but
> > impacting self-compatibility and long term maintenance. Messing the
> > foundations and defaults is not innovation. Try building a home when
> > the project constantly changes during the process, when you have 10
> > floors ready and suddenly you need to change pavements. Innovation is
> > when you create new functionality and give users a choice without
> > breaking existing working stuff.
> >
> >
> > Back to the point, this discussion touched important area, lets focus
> > on how to design a versatile CRC(16/32) API that would keep things
> > operational and self-compatible, but create a new user selectable
> > choices/alternatives. That seems the best constructive way forward :-)
> >
> > Thanks! :-)
> > Tomek
> >
> --
> Peter Barada
> peter.barada@gmail.com
>
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Peter Barada <pe...@gmail.com>.
+1 regarding Tomek's comments.
I'm all for documenting the current semantics of CRCs used by Nuttx and
expanding function names where they match well known standard CRCs, but
any effort to change(or worse make configurable) the semantics of CRCs
as currently used in Nuttx leads to a world of hurt...
I think that a CRC API that keeps things self-compatible, doesn't
sacrifice performance/footprint, and allows for underlying HW
implementation would be a good thing(tm). :-)
On 4/8/25 13:58, Tomek CEDRO wrote:
> On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com> wrote:
>> 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.
> I don't agree with this approach. Some defaults were set in NuttX and
> these defaults assure self-compatibility in various components that we
> should treat as sacred because people depend on it. Maintenance cost
> is nowadays higher than development cost unfortunately. We cannot
> change whatever we like whenever we like and blame users that their
> stuff stops working because of our upstream changes. There are
> commercial and industrial products running on NuttX and we should keep
> that in mind.
>
> Its not about how quickly we can change things, but how to add new
> features as an option/alternative without destroying existing working
> stuff.
>
> NuttX is like a foundation, it should be solid, so many things can be
> built on top of it. We should not change the foundations, not allow
> building different things at the same time in the same place which is
> impossible. We should offer a choice, not enforce changes.
>
> Linux may not be the best "reference" as it tends to change so often
> many people abandoned it as serious solution. Its a maintenance
> nightmare or single-use solution if you don't care what is inside.
> Unfortunately Linux is most popular so most software and drivers are
> written initially for Linux that propagates problems to all related OS
> (i.e. FreeBSD drm/kms video drivers), we try to avoid that in NuttX.
> Even Rust was not able to cope with Linux's internal changes pace, so
> they abandoned in-kernel maintenance and started writing from scratch
> RedoxOS in pure Rust, which seems to be long but reasonable path -
> people will have choice whether use Linux or switch to Redox, maybe in
> the long run Redox wins because of long term self-compatibility. Also
> in NuttX we have Rust port that does not impact all users, only
> interested folks can enable Rust if they want it, no one else is
> impacted, users have choice. I am sure the same approach can be
> applied to CRC stuff :-)
>
>
>> 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.
> The last sentence is completely wrong. Its not about "preference" but
> impacting self-compatibility and long term maintenance. Messing the
> foundations and defaults is not innovation. Try building a home when
> the project constantly changes during the process, when you have 10
> floors ready and suddenly you need to change pavements. Innovation is
> when you create new functionality and give users a choice without
> breaking existing working stuff.
>
>
> Back to the point, this discussion touched important area, lets focus
> on how to design a versatile CRC(16/32) API that would keep things
> operational and self-compatible, but create a new user selectable
> choices/alternatives. That seems the best constructive way forward :-)
>
> Thanks! :-)
> Tomek
>
--
Peter Barada
peter.barada@gmail.com
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
On Wed, 9 Apr 2025 at 03:43, Sebastien Lorquet <se...@lorquet.fr> wrote:
> >
> >> 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.
> >
> This is not a productive reply. Telling me to "f... off" with my own
> proprietary fork is not how collaboration works.
>
> Sebastien
Proprietary code is not how open source collaboration works. Plain and
simple. I only care about code I can see and change. Stabilizing
out-of-tree code is out of scope and none of my business unless I am under
contract. This is not an attack on anyone. Just common sense.
But that is not the point I was making. I was suggesting that we should try
to set up code so that something like CONFIG_FOO_BAR=31 saved in the fork
can preserve its meaning even if upstream later changes the value to 5.
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
>
>> 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.
>
This is not a productive reply. Telling me to "f... off" with my own
proprietary fork is not how collaboration works.
Sebastien
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
On Tue, 8 Apr 2025 at 14:49, Xiang Xiao <xi...@gmail.com> wrote:
> On Wed, Apr 9, 2025 at 2:02 AM Lwazi Dube <lw...@gmail.com> wrote:
>
> > On Tue, 8 Apr 2025 at 13:32, Xiang Xiao <xi...@gmail.com>
> wrote:
> >
> > > On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube <lw...@gmail.com> wrote:
> > >
> > > > On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet <sebastien@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
> > > > }
> > > >
> > >
> > > It's a very bad idea to use Kconfig to change the function's behaviour
> > like
> > > this.
> > >
> > For example, y/zmodem calls crc16 which expects the result same as
> > > crc16xmodempart.
> > > With this change, y/zmodem works fine when you select
> > CONFIG_CRC16_XMODEM,
> > > but stops working when you select CONFIG_CRC16_IBM.
> > > To make y/zmodem working with any choice, you have to change crc16 to
> > > crc16xmodempart.
> > > All code which calls crc16 before, must change to either crc16ibmpart
> or
> > > crc16xmodempart, which means crc16 can't be used in any portable code.
> > > Do you really want this behaviour?
> > >
> > No. Going forward, you should call crc16 if you want IBM. Otherwise call
> > the right thing.
> >
> Kconfig was for preserving historical nuttx behaviour for those who don't
> > want to keep up with upstream. It is not perfect.
> >
>
> So, we should change onewire_crc16 to crc16 per your suggestion:
>
> https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
> When a user upgraded to this version with CONFIG_CRC16_XMODEM, 1wire driver
> stopped working suddenly.
> Changing the function behaviour by Kconfig doesn't improve any
> compatibility, but makes the user write the portable code very hard.
>
Agreed.
Someone else suggested Kconfig. I agreed and typed the code to make sure I
understood what they meant.
I think you have given enough reasons for me to abandon the Kconfig idea.
And there is enough resistance in the replies :)
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Xiang Xiao <xi...@gmail.com>.
On Wed, Apr 9, 2025 at 2:02 AM Lwazi Dube <lw...@gmail.com> wrote:
> On Tue, 8 Apr 2025 at 13:32, Xiang Xiao <xi...@gmail.com> wrote:
>
> > On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube <lw...@gmail.com> wrote:
> >
> > > On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet <se...@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
> > > }
> > >
> >
> > It's a very bad idea to use Kconfig to change the function's behaviour
> like
> > this.
> >
> For example, y/zmodem calls crc16 which expects the result same as
> > crc16xmodempart.
> > With this change, y/zmodem works fine when you select
> CONFIG_CRC16_XMODEM,
> > but stops working when you select CONFIG_CRC16_IBM.
> > To make y/zmodem working with any choice, you have to change crc16 to
> > crc16xmodempart.
> > All code which calls crc16 before, must change to either crc16ibmpart or
> > crc16xmodempart, which means crc16 can't be used in any portable code.
> > Do you really want this behaviour?
> >
> No. Going forward, you should call crc16 if you want IBM. Otherwise call
> the right thing.
>
Kconfig was for preserving historical nuttx behaviour for those who don't
> want to keep up with upstream. It is not perfect.
>
So, we should change onewire_crc16 to crc16 per your suggestion:
https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
When a user upgraded to this version with CONFIG_CRC16_XMODEM, 1wire driver
stopped working suddenly.
Changing the function behaviour by Kconfig doesn't improve any
compatibility, but makes the user write the portable code very hard.
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
On Tue, 8 Apr 2025 at 13:32, Xiang Xiao <xi...@gmail.com> wrote:
> On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube <lw...@gmail.com> wrote:
>
> > On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet <se...@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
> > }
> >
>
> It's a very bad idea to use Kconfig to change the function's behaviour like
> this.
>
For example, y/zmodem calls crc16 which expects the result same as
> crc16xmodempart.
> With this change, y/zmodem works fine when you select CONFIG_CRC16_XMODEM,
> but stops working when you select CONFIG_CRC16_IBM.
> To make y/zmodem working with any choice, you have to change crc16 to
> crc16xmodempart.
> All code which calls crc16 before, must change to either crc16ibmpart or
> crc16xmodempart, which means crc16 can't be used in any portable code.
> Do you really want this behaviour?
>
No. Going forward, you should call crc16 if you want IBM. Otherwise call
the right thing.
Kconfig was for preserving historical nuttx behaviour for those who don't
want to keep up with upstream. It is not perfect.
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Xiang Xiao <xi...@gmail.com>.
On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube <lw...@gmail.com> wrote:
> On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet <se...@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
> }
>
It's a very bad idea to use Kconfig to change the function's behaviour like
this.
For example, y/zmodem calls crc16 which expects the result same as
crc16xmodempart.
With this change, y/zmodem works fine when you select CONFIG_CRC16_XMODEM,
but stops working when you select CONFIG_CRC16_IBM.
To make y/zmodem working with any choice, you have to change crc16 to
crc16xmodempart.
All code which calls crc16 before, must change to either crc16ibmpart or
crc16xmodempart, which means crc16 can't be used in any portable code.
Do you really want this behaviour?
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by chao an <ma...@gmail.com>.
I can empathize. But we just don't want to fill this regret again in the
new building.
The lack of standards is currently the biggest issue hindering the
promotion of this proposal.
Another interesting thing, I'd like to share another data from github:
if we search for the lookup table of crc16 on GitHub, you'll find that
CRC-16/IBM with a higher use rate:
CRC-16/IBM: 3.1k
https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
[image: image.png]
CRC-16/XMODEM: 304
https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
[image: image.png]
BRs,
Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道：
> On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com>
> wrote:
> > > > > An open source project's ability to innovate should not be
> > > > > held up by your preferences.
> > > >
> > > > The last sentence is completely wrong. Its not about "preference" but
> > > > impacting self-compatibility and long term maintenance. Messing the
> > > > foundations and defaults is not innovation. Try building a home when
> > > > the project constantly changes during the process, when you have 10
> > > > floors ready and suddenly you need to change pavements. Innovation is
> > > > when you create new functionality and give users a choice without
> > > > breaking existing working stuff.
> >
> > So you think it's more important to maintain your current 10 floors
> > building, and it's none of your business if a 100 floors skyscraper
> appears
> > in the future? so could you afford all the developer time spent on this
> > kind of problem?
>
> Anchao, what I meant was to finish 10 floor building as planned
> (development), let people live inside that building (maintenance), and
> move development resources to 100 floor building as planned, without
> changing plans in the middle of construction, not getting stuck on 10
> floor building construction because plans change all the time and
> never getting to that 100 floor building. Its good to have solid
> immutable tools that you can depend on. Imagine there are devices
> already deployed out there that may not be possible to update, yes
> maintenance (in terms of keeping them inter-operational) may be the
> priority in that case, because replacing all devices may wipe out the
> company and leave owner with ubearable financial debt.
>
> I know this CRC is an important and quite hard problem, and I hope
> there can be a win-win solution where users have choice when they need
> one, thank you for bringing this up to the attention.. to be honest I
> have no clue what is the best solution here if there is no standard to
> relay on :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Tomek CEDRO <to...@cedro.info>.
On Wed, Apr 9, 2025 at 3:45 AM chao an <ma...@gmail.com> wrote:
> > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com> wrote:
> > > > An open source project's ability to innovate should not be
> > > > held up by your preferences.
> > >
> > > The last sentence is completely wrong. Its not about "preference" but
> > > impacting self-compatibility and long term maintenance. Messing the
> > > foundations and defaults is not innovation. Try building a home when
> > > the project constantly changes during the process, when you have 10
> > > floors ready and suddenly you need to change pavements. Innovation is
> > > when you create new functionality and give users a choice without
> > > breaking existing working stuff.
>
> So you think it's more important to maintain your current 10 floors
> building, and it's none of your business if a 100 floors skyscraper appears
> in the future? so could you afford all the developer time spent on this
> kind of problem?
Anchao, what I meant was to finish 10 floor building as planned
(development), let people live inside that building (maintenance), and
move development resources to 100 floor building as planned, without
changing plans in the middle of construction, not getting stuck on 10
floor building construction because plans change all the time and
never getting to that 100 floor building. Its good to have solid
immutable tools that you can depend on. Imagine there are devices
already deployed out there that may not be possible to update, yes
maintenance (in terms of keeping them inter-operational) may be the
priority in that case, because replacing all devices may wipe out the
company and leave owner with ubearable financial debt.
I know this CRC is an important and quite hard problem, and I hope
there can be a win-win solution where users have choice when they need
one, thank you for bringing this up to the attention.. to be honest I
have no clue what is the best solution here if there is no standard to
relay on :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by chao an <ma...@gmail.com>.
>
>
> > The last sentence is completely wrong. Its not about "preference" but
> > impacting self-compatibility and long term maintenance. Messing the
> > foundations and defaults is not innovation. Try building a home when
> > the project constantly changes during the process, when you have 10
> > floors ready and suddenly you need to change pavements. Innovation is
> > when you create new functionality and give users a choice without
> > breaking existing working stuff.
So you think it's more important to maintain your current 10 floors
building, and it's none of your business if a 100 floors skyscraper appears
in the future? so could you afford all the developer time spent on this
kind of problem?
BRs,
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Tomek CEDRO <to...@cedro.info>.
On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lw...@gmail.com> wrote:
> 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.
I don't agree with this approach. Some defaults were set in NuttX and
these defaults assure self-compatibility in various components that we
should treat as sacred because people depend on it. Maintenance cost
is nowadays higher than development cost unfortunately. We cannot
change whatever we like whenever we like and blame users that their
stuff stops working because of our upstream changes. There are
commercial and industrial products running on NuttX and we should keep
that in mind.
Its not about how quickly we can change things, but how to add new
features as an option/alternative without destroying existing working
stuff.
NuttX is like a foundation, it should be solid, so many things can be
built on top of it. We should not change the foundations, not allow
building different things at the same time in the same place which is
impossible. We should offer a choice, not enforce changes.
Linux may not be the best "reference" as it tends to change so often
many people abandoned it as serious solution. Its a maintenance
nightmare or single-use solution if you don't care what is inside.
Unfortunately Linux is most popular so most software and drivers are
written initially for Linux that propagates problems to all related OS
(i.e. FreeBSD drm/kms video drivers), we try to avoid that in NuttX.
Even Rust was not able to cope with Linux's internal changes pace, so
they abandoned in-kernel maintenance and started writing from scratch
RedoxOS in pure Rust, which seems to be long but reasonable path -
people will have choice whether use Linux or switch to Redox, maybe in
the long run Redox wins because of long term self-compatibility. Also
in NuttX we have Rust port that does not impact all users, only
interested folks can enable Rust if they want it, no one else is
impacted, users have choice. I am sure the same approach can be
applied to CRC stuff :-)
> 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.
The last sentence is completely wrong. Its not about "preference" but
impacting self-compatibility and long term maintenance. Messing the
foundations and defaults is not innovation. Try building a home when
the project constantly changes during the process, when you have 10
floors ready and suddenly you need to change pavements. Innovation is
when you create new functionality and give users a choice without
breaking existing working stuff.
Back to the point, this discussion touched important area, lets focus
on how to design a versatile CRC(16/32) API that would keep things
operational and self-compatible, but create a new user selectable
choices/alternatives. That seems the best constructive way forward :-)
Thanks! :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet <se...@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.
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
Nathan proposal to have a kconfig, with a default to the historical
algorithm, is a good solution.
I Maintain, DO NOT CHANGE THE DEFAULT CRC ROUTINE.
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
Compatibility with other platforms that do not define all the explicit
parameters of their CRC is a fallacy and is not a good enough reason to
break existing systems in a potentially dangerous way.
It's not worth the risk.
Sebastien
On 08/04/2025 06:43, Alin Jerpelea wrote:
> +1 if there is backwards compatibility and proper documentation
>
> On Tue, 8 Apr 2025, 04:00 chao an, <ma...@gmail.com> wrote:
>
>> Hi, Greg，
>>
>> Glad to hear your voice.
>>
>> In the current crc16 implementation, we have provided 3 variants. The
>> default crc16 semantics is CRC-16/XMODEM:
>>
>> CRC-16/XMODEM:
>> crc16
>> crc16part
>> https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16.c
>>
>> CRC-16/CCITT-TRUE:
>> crc16ccitt
>> crc16ccittpart
>>
>> https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16ccitt.c
>>
>> CRC-16/IBM:
>> crc16ibm
>> crc16ibmpart
>>
>> https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16ibm.c
>>
>>
>> In PR16147, I mapped the default crc16 implementation to CRC-16/IBM. NuttX
>> did not abandon other variants, but provided more specific interface
>> implementations:
>> https://github.com/apache/nuttx/pull/16147
>>
>> CRC-16/XMODEM:
>> crc16xmodem
>> crc16xmodempart
>>
>> CRC-16/CCITT-TRUE:
>> crc16ccitt
>> crc16ccittpart
>>
>> CRC-16/IBM:
>> crc16ibm
>> crc16ibmpart
>>
>> New crc16 implement, just mapping these APIs to CRC-16/IBM, developers are
>> free to choose which variant to use
This is not "JUST" mapping.
This JUST mapping will break production systems that use the old
implementation.
Dont do this.
I insist.
Sebastien
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Alin Jerpelea <je...@gmail.com>.
+1 if there is backwards compatibility and proper documentation
On Tue, 8 Apr 2025, 04:00 chao an, <ma...@gmail.com> wrote:
> Hi, Greg，
>
> Glad to hear your voice.
>
> In the current crc16 implementation, we have provided 3 variants. The
> default crc16 semantics is CRC-16/XMODEM:
>
> CRC-16/XMODEM:
> crc16
> crc16part
> https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16.c
>
> CRC-16/CCITT-TRUE:
> crc16ccitt
> crc16ccittpart
>
> https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16ccitt.c
>
> CRC-16/IBM:
> crc16ibm
> crc16ibmpart
>
> https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16ibm.c
>
>
> In PR16147, I mapped the default crc16 implementation to CRC-16/IBM. NuttX
> did not abandon other variants, but provided more specific interface
> implementations:
> https://github.com/apache/nuttx/pull/16147
>
> CRC-16/XMODEM:
> crc16xmodem
> crc16xmodempart
>
> CRC-16/CCITT-TRUE:
> crc16ccitt
> crc16ccittpart
>
> CRC-16/IBM:
> crc16ibm
> crc16ibmpart
>
> New crc16 implement, just mapping these APIs to CRC-16/IBM, developers are
> free to choose which variant to use
>
> uint16_t crc16part(FAR const uint8_t *src, size_t len, uint16_t crc16val)
> {
> return crc16ibmpart(src, len, crc16val);
> }
>
> uint16_t crc16(FAR const uint8_t *src, size_t len)
> {
> return crc16ibmpart(src, len, 0);
> }
>
> BRs,
>
> Gregory Nutt <sp...@gmail.com> 于2025年4月8日周二 09:43写道：
>
> > > What if you need both versions at the same time? Rather than an option
> > to use one or the the other, options to enable one or both would be more
> > flexible.
> >
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by chao an <ma...@gmail.com>.
Hi, Greg，
Glad to hear your voice.
In the current crc16 implementation, we have provided 3 variants. The
default crc16 semantics is CRC-16/XMODEM:
CRC-16/XMODEM:
crc16
crc16part
https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16.c
CRC-16/CCITT-TRUE:
crc16ccitt
crc16ccittpart
https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16ccitt.c
CRC-16/IBM:
crc16ibm
crc16ibmpart
https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16ibm.c
In PR16147, I mapped the default crc16 implementation to CRC-16/IBM. NuttX
did not abandon other variants, but provided more specific interface
implementations:
https://github.com/apache/nuttx/pull/16147
CRC-16/XMODEM:
crc16xmodem
crc16xmodempart
CRC-16/CCITT-TRUE:
crc16ccitt
crc16ccittpart
CRC-16/IBM:
crc16ibm
crc16ibmpart
New crc16 implement, just mapping these APIs to CRC-16/IBM, developers are
free to choose which variant to use
uint16_t crc16part(FAR const uint8_t *src, size_t len, uint16_t crc16val)
{
return crc16ibmpart(src, len, crc16val);
}
uint16_t crc16(FAR const uint8_t *src, size_t len)
{
return crc16ibmpart(src, len, 0);
}
BRs,
Gregory Nutt <sp...@gmail.com> 于2025年4月8日周二 09:43写道：
> > What if you need both versions at the same time? Rather than an option
> to use one or the the other, options to enable one or both would be more
> flexible.
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Gregory Nutt <sp...@gmail.com>.
> What if you need both versions at the same time? Rather than an option to use one or the the other, options to enable one or both would be more flexible.
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by chao an <ma...@gmail.com>.
I still insist on my opinion that compatibility with popular operating
systems is the best choice
The issues we are discussing now are limited to the premise of not breaking
existing products, but your decision has broken all future programs that
want to compatible NuttX but these programs have good compatibility with
linux/openbsd/freebsd
NuttX is a future-oriented operating system. Try to imagine that in the
future, people will continue to spend more energy to debug their own
programs because of crc16 problems. Isn’t that unreasonable?
NuttX is still on the path of continuous progress. It is not a dead
project. It is terrible to give up future evolution in order to be
compatible with the applications of the previous 7 years.
Think about your children and friends’ experience with NuttX.
BRs,
Lwazi Dube <lw...@gmail.com> 于2025年4月8日周二 07:01写道：
> On Mon, 7 Apr 2025 at 18:21, Nathan Hartman <ha...@gmail.com>
> wrote:
>
> > -1 from me also, but please read further:
> >
> > I would vote +1 if there is a Kconfig to select crc16 type, and
> > current (backwards-compatible) type is default. This way, existing
> > applications will not break suddenly, but developers who need
> > different CRC can choose it from Kconfig.
> >
>
> Does any code borrowed from Linux/Free/OpenBSD count? That code is already
> broken by default. That is why he is asking to change the default. The
> resulting 2 broken NuttX apps are just collateral damage /s.
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
On Mon, 7 Apr 2025 at 18:21, Nathan Hartman <ha...@gmail.com>
wrote:
> -1 from me also, but please read further:
>
> I would vote +1 if there is a Kconfig to select crc16 type, and
> current (backwards-compatible) type is default. This way, existing
> applications will not break suddenly, but developers who need
> different CRC can choose it from Kconfig.
>
Does any code borrowed from Linux/Free/OpenBSD count? That code is already
broken by default. That is why he is asking to change the default. The
resulting 2 broken NuttX apps are just collateral damage /s.
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Nathan Hartman <ha...@gmail.com>.
-1 from me also, but please read further:
I would vote +1 if there is a Kconfig to select crc16 type, and
current (backwards-compatible) type is default. This way, existing
applications will not break suddenly, but developers who need
different CRC can choose it from Kconfig.
In addition, I like Sebastien's proposed solution to add a generic
crc16 that can calculate any CRC based on parameters. This will need
different naming obviously, since it cannot clash with existing
functions.
Thanks,
Nathan
On Mon, Apr 7, 2025 at 4:54 PM Tomek CEDRO <to...@cedro.info> wrote:
>
> -1 from me, sorry, reading previous messages this seems to break too
> many things, just to adhere to a specific solution that is not
> standard compliant too.. we need to search for better solution :-)
>
> Would it be possible to create generic crc16() and crc32() calls, like
> Alan and Sebastien suggests, that would provide / support various
> implementations based on parameters provided? If so then we could
> replace old methods with a wrapper to a new call with
> backward-compatible parameters? For start a good API would have to be
> defined and some basic / required / used implementations.. that could
> be extended with new required implementations in future but still
> self-compatible interface?
>
> Thanks :-)
> Tomek
>
> On Mon, Apr 7, 2025 at 7:22 PM Alan C. Assis <ac...@gmail.com> wrote:
> >
> > Hi Sebastien,
> >
> > Yes, maybe your suggestion to create a simple/base crc16 that will be the
> > base for other crc16 variants could make more sense.
> >
> > It would be nice to have something similar for crc32 as well.
> >
> > There are many variations listed in this wikipedia page:
> >
> > https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Polynomial_representations
> >
> > BR,
> >
> > Alan
> >
> > On Mon, Apr 7, 2025 at 12:29 PM Sebastien Lorquet <se...@lorquet.fr>
> > wrote:
> >
> > > Hello,
> > >
> > > I understand the need for improvement but I think there is a better
> > > solution that I am describing at the bottom of this email after the
> > > rationale.
> > >
> > > I will keep my request to not break crc16
> > >
> > > Also I explain why changing it is useless.
> > >
> > >
> > > -- why it is useless to change crc16 --
> > >
> > > Again, there is NO definition for a single CRC16. There is no CRC16
> > > standard algorithm. None is better than the other (as a first order
> > > approximation).
> > >
> > > A CRC16 has several parameters and these all must be specified to be
> > > sure that it's well defined.
> > >
> > > Given a polynomial, you can still change the initial value, the final
> > > xor, and the order of input and output bits.
> > >
> > > These parameters are also encoded in a CRC16 and they are rarely mentioned.
> > >
> > >
> > > So "compatibility" with any other platform is a fallacy, because there
> > > is no standard, the choice of a CRC is just a de facto rule of the
> > > strongest.
> > >
> > > So there is no point to follow linux compatibility or whatever you name
> > > because these are not, and will never be, recognized standard.
> > >
> > > This is not linux's fault. This is not nuttx's fault. this is CRC16
> > > being badly defined.
> > >
> > >
> > > -- what can be done better --
> > >
> > > The best option, to my cryptograpic experience of 15 years, is to
> > > provide a generic crc16 routine, and implement all variants using
> > > parameters.
> > >
> > > THEN, everywhere you need compatibility, you SPECIFY the crc16 details
> > > that must be used to ensure compatibility with this particular app.
> > >
> > > It can be made compact OR fast, that could also be a build or runtime
> > > option.
> > >
> > >
> > > This would have my support.
> > >
> > > And then, use this to continue to provide the default crc16
> > > implementation that was decided a long time ago.
> > >
> > > Again, I repeat, do NOT break the default crc16. I reckon that it is
> > > badly defined and maybe unusual, but it's there, and changing it will
> > > catastrophically break user code that we are not even remotely aware.
> > >
> > > Also, I am not suggesting that basing ANY system on the default CRC
> > > routines of an operating system is a clean design. But it will exist
> > > nevertheless. so, it must be stable.
> > >
> > >
> > > Here is my proposal:
> > >
> > > -define a set of new configurable CRC routines that works like SHA256
> > > (for example a crc16 context storing parameters, and a
> > > crc16_generic_init(&context, CRC_PARAMS_WHATEVER), with
> > > crc16_generic_update, crc16_generic_final
> > >
> > > Use this to remplement all existing crc16 you find in nuttx.
> > >
> > > Use the new API to implement any new CRC that will need proper and
> > > strong specified interoperable parameters
> > >
> > > This will allow NuttX to claim a clean and well defined CRC16 API.
> > >
> > >
> > > -- conclusion --
> > >
> > > Any change you do to change an arbitrary CRC16 by another CRC16 will be
> > >
> > > 1 - frustrating
> > >
> > > 2 - catastrophic for long term users and unknown code
> > >
> > > 3 - not even closer to any standard
> > >
> > >
> > > This is my attempt to suggest a clean and better solution to the crc16
> > > problem. A simple substitution, with bad words, is just replacing trash
> > > with another trash. Absolutely useless.
> > >
> > > There is a better way.
> > >
> > >
> > > Again and again, dont break the default crc16. Consider it legacy. Keep
> > > it. Dont break user protocols and mass storage structures.
> > >
> > >
> > > Sebastien
> > >
> > >
> > > On 07/04/2025 17:09, Alan C. Assis wrote:
> > > > Hi Sebastien,
> > > >
> > > > This is a case where compatibility is more important than API stability.
> > > >
> > > > New developers are spending a lot of time trying to figure out why
> > > existing
> > > > code is not working and end up discovering that the issue is the CRC
> > > > incompatible with Linux or other OS.
> > > >
> > > > If breaking API is an issue, we could propose these modifications to the
> > > > next major version (version 13).
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > >
> > > > On Mon, Apr 7, 2025 at 11:27 AM Sebastien Lorquet <se...@lorquet.fr>
> > > > wrote:
> > > >
> > > >> Hello,
> > > >>
> > > >> No. No way I will EVER be convinced by this change. The default CRC MUST
> > > >> NOT change.
> > > >>
> > > >>
> > > >> I have been maintaining proprietary code bases for 15 years, and I very
> > > >> well know this frustration, but the answer is still no. A default
> > > >> cryptographic algorithm can NOT change.
> > > >>
> > > >> All you can do is make sure new code uses your new routines, which are
> > > >> now appropriately named and form a new stable API.
> > > >>
> > > >> But PLEASE keep the API stable.
> > > >>
> > > >>
> > > >> (One-wire has its own crc and if you change it components will stop
> > > >> working thats all.)
> > > >>
> > > >>
> > > >> CRC used in a "live" system, like a protocol: if you change it, you cant
> > > >> communicate with other peers of the network
> > > >>
> > > >> CRC used in a storage system: You break the on-disk storage structure
> > > >> and the user looses all their storage.
> > > >>
> > > >>
> > > >> If you change ANY CRC across a release, it results in a catastrophic
> > > >> failure.
> > > >>
> > > >> Please understand: You CANT change a CRC definition if it has been used
> > > >> ONCE by anyone, even if you are not aware of it.
> > > >>
> > > >> And as a reminder, the visible code base is only the tip of the iceberg.
> > > >>
> > > >> This breaking change will silently break user code that is already
> > > >> released.
> > > >>
> > > >>
> > > >> So changing the default crc16 implementation NOW is too much of a
> > > >> responsibility.
> > > >>
> > > >> I refuse this change.
> > > >>
> > > >>
> > > >> As said, I am very welcoming to more CRC algorithms, given they do not
> > > >> replace the default.
> > > >>
> > > >> PLEASE respect this, at least by waiting for another opinion in addition
> > > >> to mine.
> > > >>
> > > >> You cant break protocols and storage systems you are not aware of.
> > > >>
> > > >>
> > > >> I am using strong wording not because I am in a bad mood, but because it
> > > >> is a really really important point, and I hope I get support from more
> > > >> project members.
> > > >>
> > > >> Again I'm very OK to add several CRC routines, or even a configurable
> > > >> CRC like crc_init_alg(CRC_TYPE_XMODEM). The CRC table can be generated
> > > >> dynamically.
> > > >>
> > > >> CRC have many different parameters
> > > >>
> > > >> -the polynomial
> > > >>
> > > >> -the initial value
> > > >>
> > > >> -the order of bits from the input
> > > >>
> > > >> -the order of bits in the CRC
> > > >>
> > > >> -the final inversion of data
> > > >>
> > > >> You cant have one crc routine for each. The general case need that much
> > > >> generality.
> > > >>
> > > >> I said please, several times. I BEG you, dont change the default CRC.
> > > >> Pretty please.
> > > >>
> > > >> Best regards,
> > > >>
> > > >> Sebastien
> > > >>
> > > >>
> > > >> On 07/04/2025 16:13, chao an wrote:
> > > >>> Hi, sebastien
> > > >>>
> > > >>> I fully understand your concerns, and I agree that changing the default
> > > >>> algorithm may cause trouble to currently active projects.
> > > >>> However, I have searched the code for the application scope of crc16 in
> > > >>> nuttx, and I found that many drivers are using customized CRC-16/IBM
> > > >>> implementations, which are not capabilities provided by the system.
> > > >>>
> > > >>> CRC-16/IBM:
> > > >>>
> > > >>> Below drivers implement need CRC-16/IBM support:
> > > >>>
> > > >>> 1. 1wire_crc private implementation:
> > > >>> (poly: 0x8005 (0xA001) initial seed: 0x0000, xor output: 0x0000)
> > > >>>
> > > >>
> > > https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
> > > >>> 2. spi/uart driver communicate with linux:
> > > >>>
> > > >>>
> > > >>
> > > https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi_slave.c#L45-L46
> > > >>
> > > https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi.c#L45-L46
> > > >>
> > > https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_uart.c#L59-L60
> > > >>> ----------------------------------------
> > > >>> CRC-16/XMODEM:
> > > >>>
> > > >>> CRC-16/XMODEM is currently only used in y/zmodem in nuttx-apps:
> > > >>>
> > > >>>
> > > >>
> > > https://github.com/apache/nuttx-apps/blob/master/system/ymodem/ymodem.c#L176
> > > >>
> > > https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_state.c#L204
> > > >>
> > > https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_proto.c#L194
> > > >>
> > > https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_send.c#L996
> > > >>> Furthermore, we found that many communication protocols are using
> > > >>> CRC-16/IBM implementation.
> > > >>> In the email, I also explained that this is because popular operating
> > > >>> systems, such as Linux/OpenBSD/FreeBSD are using CRC-16/IBM by default:
> > > >>>
> > > >>> OpenBSD:
> > > >>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> > > >>>
> > > >>> FreeBSD:
> > > >>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> > > >>>
> > > >>> Linux:
> > > >>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
> > > >>>
> > > >>> So I want to convince you further, I think this is better for the
> > > future
> > > >>> development of NuttX
> > > >>>
> > > >>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月7日周一 21:19写道：
> > > >>>
> > > >>>> Hello,
> > > >>>>
> > > >>>> Compatibility with other OSes in this domain is dubious.
> > > >>>>
> > > >>>> What is the actual need for cross-OS crc16 compatibility?
> > > >>>>
> > > >>>> Self-compatibilty is much more important. What is a non volatile
> > > storage
> > > >>>> structure was created by the old CRC (old release) is checked with the
> > > >>>> new CRC?
> > > >>>>
> > > >>>> This will be an immediate fatal error with potentially grave
> > > >> consequences.
> > > >>>> I am FULLY AGAINST this change.
> > > >>>>
> > > >>>> It MUST NOT PROCEED.
> > > >>>>
> > > >>>> I still think you can introduce additional routines to compute other
> > > CRC
> > > >>>> variations, but the default crc MUST DEFINITELY NOT CHANGE.
> > > >>>>
> > > >>>> Use the new routines in a wrapper in your code, but DO NOT CHANGE the
> > > >>>> default CRC algorithm
> > > >>>>
> > > >>>> This is an ABSOLUTELY CRITICAL ISSUE!
> > > >>>>
> > > >>>> -1
> > > >>>>
> > > >>>> Sebastien
> > > >>>>
> > > >>>>
> > > >>>> On 07/04/2025 10:35, chao an wrote:
> > > >>>>> Hi Community,
> > > >>>>>
> > > >>>>> I plan to switch the default CRC16 algorithm directory of NuttX from
> > > >>>>> CRC-16/XMODEM to CRC-16/IBM:
> > > >>>>> https://github.com/apache/nuttx/pull/16147
> > > >>>>>
> > > >>>>> CRC-16/XMODEM as the default implementation has significant
> > > >> limitations,
> > > >>>>> especially when communicating with popular operating systems and it
> > > >> comes
> > > >>>>> to CRC encryption verification, the algorithm needs to be switched.
> > > >>>>>
> > > >>>>> I have conducted research on POSIX-compatible operating systems, and
> > > >>>> almost
> > > >>>>> all of them use CRC-16/IBM as the default implementation:
> > > >>>>>
> > > >>>>> OpenBSD:
> > > >>>>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> > > >>>>>
> > > >>>>> FreeBSD:
> > > >>>>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> > > >>>>>
> > > >>>>> Linux:
> > > >>>>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
> > > >>>>>
> > > >>>>> So I need your vote here:
> > > >>>>> If you prefer CRC-16/XMODEM, please reply with -1.
> > > >>>>> If you recommend CRC-16/IBM, please reply with +1.
> > > >>>>>
> > > >>>>> BRs,
> > > >>>>>
> > >
>
>
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Tomek CEDRO <to...@cedro.info>.
-1 from me, sorry, reading previous messages this seems to break too
many things, just to adhere to a specific solution that is not
standard compliant too.. we need to search for better solution :-)
Would it be possible to create generic crc16() and crc32() calls, like
Alan and Sebastien suggests, that would provide / support various
implementations based on parameters provided? If so then we could
replace old methods with a wrapper to a new call with
backward-compatible parameters? For start a good API would have to be
defined and some basic / required / used implementations.. that could
be extended with new required implementations in future but still
self-compatible interface?
Thanks :-)
Tomek
On Mon, Apr 7, 2025 at 7:22 PM Alan C. Assis <ac...@gmail.com> wrote:
>
> Hi Sebastien,
>
> Yes, maybe your suggestion to create a simple/base crc16 that will be the
> base for other crc16 variants could make more sense.
>
> It would be nice to have something similar for crc32 as well.
>
> There are many variations listed in this wikipedia page:
>
> https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Polynomial_representations
>
> BR,
>
> Alan
>
> On Mon, Apr 7, 2025 at 12:29 PM Sebastien Lorquet <se...@lorquet.fr>
> wrote:
>
> > Hello,
> >
> > I understand the need for improvement but I think there is a better
> > solution that I am describing at the bottom of this email after the
> > rationale.
> >
> > I will keep my request to not break crc16
> >
> > Also I explain why changing it is useless.
> >
> >
> > -- why it is useless to change crc16 --
> >
> > Again, there is NO definition for a single CRC16. There is no CRC16
> > standard algorithm. None is better than the other (as a first order
> > approximation).
> >
> > A CRC16 has several parameters and these all must be specified to be
> > sure that it's well defined.
> >
> > Given a polynomial, you can still change the initial value, the final
> > xor, and the order of input and output bits.
> >
> > These parameters are also encoded in a CRC16 and they are rarely mentioned.
> >
> >
> > So "compatibility" with any other platform is a fallacy, because there
> > is no standard, the choice of a CRC is just a de facto rule of the
> > strongest.
> >
> > So there is no point to follow linux compatibility or whatever you name
> > because these are not, and will never be, recognized standard.
> >
> > This is not linux's fault. This is not nuttx's fault. this is CRC16
> > being badly defined.
> >
> >
> > -- what can be done better --
> >
> > The best option, to my cryptograpic experience of 15 years, is to
> > provide a generic crc16 routine, and implement all variants using
> > parameters.
> >
> > THEN, everywhere you need compatibility, you SPECIFY the crc16 details
> > that must be used to ensure compatibility with this particular app.
> >
> > It can be made compact OR fast, that could also be a build or runtime
> > option.
> >
> >
> > This would have my support.
> >
> > And then, use this to continue to provide the default crc16
> > implementation that was decided a long time ago.
> >
> > Again, I repeat, do NOT break the default crc16. I reckon that it is
> > badly defined and maybe unusual, but it's there, and changing it will
> > catastrophically break user code that we are not even remotely aware.
> >
> > Also, I am not suggesting that basing ANY system on the default CRC
> > routines of an operating system is a clean design. But it will exist
> > nevertheless. so, it must be stable.
> >
> >
> > Here is my proposal:
> >
> > -define a set of new configurable CRC routines that works like SHA256
> > (for example a crc16 context storing parameters, and a
> > crc16_generic_init(&context, CRC_PARAMS_WHATEVER), with
> > crc16_generic_update, crc16_generic_final
> >
> > Use this to remplement all existing crc16 you find in nuttx.
> >
> > Use the new API to implement any new CRC that will need proper and
> > strong specified interoperable parameters
> >
> > This will allow NuttX to claim a clean and well defined CRC16 API.
> >
> >
> > -- conclusion --
> >
> > Any change you do to change an arbitrary CRC16 by another CRC16 will be
> >
> > 1 - frustrating
> >
> > 2 - catastrophic for long term users and unknown code
> >
> > 3 - not even closer to any standard
> >
> >
> > This is my attempt to suggest a clean and better solution to the crc16
> > problem. A simple substitution, with bad words, is just replacing trash
> > with another trash. Absolutely useless.
> >
> > There is a better way.
> >
> >
> > Again and again, dont break the default crc16. Consider it legacy. Keep
> > it. Dont break user protocols and mass storage structures.
> >
> >
> > Sebastien
> >
> >
> > On 07/04/2025 17:09, Alan C. Assis wrote:
> > > Hi Sebastien,
> > >
> > > This is a case where compatibility is more important than API stability.
> > >
> > > New developers are spending a lot of time trying to figure out why
> > existing
> > > code is not working and end up discovering that the issue is the CRC
> > > incompatible with Linux or other OS.
> > >
> > > If breaking API is an issue, we could propose these modifications to the
> > > next major version (version 13).
> > >
> > > BR,
> > >
> > > Alan
> > >
> > >
> > > On Mon, Apr 7, 2025 at 11:27 AM Sebastien Lorquet <se...@lorquet.fr>
> > > wrote:
> > >
> > >> Hello,
> > >>
> > >> No. No way I will EVER be convinced by this change. The default CRC MUST
> > >> NOT change.
> > >>
> > >>
> > >> I have been maintaining proprietary code bases for 15 years, and I very
> > >> well know this frustration, but the answer is still no. A default
> > >> cryptographic algorithm can NOT change.
> > >>
> > >> All you can do is make sure new code uses your new routines, which are
> > >> now appropriately named and form a new stable API.
> > >>
> > >> But PLEASE keep the API stable.
> > >>
> > >>
> > >> (One-wire has its own crc and if you change it components will stop
> > >> working thats all.)
> > >>
> > >>
> > >> CRC used in a "live" system, like a protocol: if you change it, you cant
> > >> communicate with other peers of the network
> > >>
> > >> CRC used in a storage system: You break the on-disk storage structure
> > >> and the user looses all their storage.
> > >>
> > >>
> > >> If you change ANY CRC across a release, it results in a catastrophic
> > >> failure.
> > >>
> > >> Please understand: You CANT change a CRC definition if it has been used
> > >> ONCE by anyone, even if you are not aware of it.
> > >>
> > >> And as a reminder, the visible code base is only the tip of the iceberg.
> > >>
> > >> This breaking change will silently break user code that is already
> > >> released.
> > >>
> > >>
> > >> So changing the default crc16 implementation NOW is too much of a
> > >> responsibility.
> > >>
> > >> I refuse this change.
> > >>
> > >>
> > >> As said, I am very welcoming to more CRC algorithms, given they do not
> > >> replace the default.
> > >>
> > >> PLEASE respect this, at least by waiting for another opinion in addition
> > >> to mine.
> > >>
> > >> You cant break protocols and storage systems you are not aware of.
> > >>
> > >>
> > >> I am using strong wording not because I am in a bad mood, but because it
> > >> is a really really important point, and I hope I get support from more
> > >> project members.
> > >>
> > >> Again I'm very OK to add several CRC routines, or even a configurable
> > >> CRC like crc_init_alg(CRC_TYPE_XMODEM). The CRC table can be generated
> > >> dynamically.
> > >>
> > >> CRC have many different parameters
> > >>
> > >> -the polynomial
> > >>
> > >> -the initial value
> > >>
> > >> -the order of bits from the input
> > >>
> > >> -the order of bits in the CRC
> > >>
> > >> -the final inversion of data
> > >>
> > >> You cant have one crc routine for each. The general case need that much
> > >> generality.
> > >>
> > >> I said please, several times. I BEG you, dont change the default CRC.
> > >> Pretty please.
> > >>
> > >> Best regards,
> > >>
> > >> Sebastien
> > >>
> > >>
> > >> On 07/04/2025 16:13, chao an wrote:
> > >>> Hi, sebastien
> > >>>
> > >>> I fully understand your concerns, and I agree that changing the default
> > >>> algorithm may cause trouble to currently active projects.
> > >>> However, I have searched the code for the application scope of crc16 in
> > >>> nuttx, and I found that many drivers are using customized CRC-16/IBM
> > >>> implementations, which are not capabilities provided by the system.
> > >>>
> > >>> CRC-16/IBM:
> > >>>
> > >>> Below drivers implement need CRC-16/IBM support:
> > >>>
> > >>> 1. 1wire_crc private implementation:
> > >>> (poly: 0x8005 (0xA001) initial seed: 0x0000, xor output: 0x0000)
> > >>>
> > >>
> > https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
> > >>> 2. spi/uart driver communicate with linux:
> > >>>
> > >>>
> > >>
> > https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi_slave.c#L45-L46
> > >>
> > https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi.c#L45-L46
> > >>
> > https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_uart.c#L59-L60
> > >>> ----------------------------------------
> > >>> CRC-16/XMODEM:
> > >>>
> > >>> CRC-16/XMODEM is currently only used in y/zmodem in nuttx-apps:
> > >>>
> > >>>
> > >>
> > https://github.com/apache/nuttx-apps/blob/master/system/ymodem/ymodem.c#L176
> > >>
> > https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_state.c#L204
> > >>
> > https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_proto.c#L194
> > >>
> > https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_send.c#L996
> > >>> Furthermore, we found that many communication protocols are using
> > >>> CRC-16/IBM implementation.
> > >>> In the email, I also explained that this is because popular operating
> > >>> systems, such as Linux/OpenBSD/FreeBSD are using CRC-16/IBM by default:
> > >>>
> > >>> OpenBSD:
> > >>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> > >>>
> > >>> FreeBSD:
> > >>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> > >>>
> > >>> Linux:
> > >>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
> > >>>
> > >>> So I want to convince you further, I think this is better for the
> > future
> > >>> development of NuttX
> > >>>
> > >>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月7日周一 21:19写道：
> > >>>
> > >>>> Hello,
> > >>>>
> > >>>> Compatibility with other OSes in this domain is dubious.
> > >>>>
> > >>>> What is the actual need for cross-OS crc16 compatibility?
> > >>>>
> > >>>> Self-compatibilty is much more important. What is a non volatile
> > storage
> > >>>> structure was created by the old CRC (old release) is checked with the
> > >>>> new CRC?
> > >>>>
> > >>>> This will be an immediate fatal error with potentially grave
> > >> consequences.
> > >>>> I am FULLY AGAINST this change.
> > >>>>
> > >>>> It MUST NOT PROCEED.
> > >>>>
> > >>>> I still think you can introduce additional routines to compute other
> > CRC
> > >>>> variations, but the default crc MUST DEFINITELY NOT CHANGE.
> > >>>>
> > >>>> Use the new routines in a wrapper in your code, but DO NOT CHANGE the
> > >>>> default CRC algorithm
> > >>>>
> > >>>> This is an ABSOLUTELY CRITICAL ISSUE!
> > >>>>
> > >>>> -1
> > >>>>
> > >>>> Sebastien
> > >>>>
> > >>>>
> > >>>> On 07/04/2025 10:35, chao an wrote:
> > >>>>> Hi Community,
> > >>>>>
> > >>>>> I plan to switch the default CRC16 algorithm directory of NuttX from
> > >>>>> CRC-16/XMODEM to CRC-16/IBM:
> > >>>>> https://github.com/apache/nuttx/pull/16147
> > >>>>>
> > >>>>> CRC-16/XMODEM as the default implementation has significant
> > >> limitations,
> > >>>>> especially when communicating with popular operating systems and it
> > >> comes
> > >>>>> to CRC encryption verification, the algorithm needs to be switched.
> > >>>>>
> > >>>>> I have conducted research on POSIX-compatible operating systems, and
> > >>>> almost
> > >>>>> all of them use CRC-16/IBM as the default implementation:
> > >>>>>
> > >>>>> OpenBSD:
> > >>>>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> > >>>>>
> > >>>>> FreeBSD:
> > >>>>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> > >>>>>
> > >>>>> Linux:
> > >>>>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
> > >>>>>
> > >>>>> So I need your vote here:
> > >>>>> If you prefer CRC-16/XMODEM, please reply with -1.
> > >>>>> If you recommend CRC-16/IBM, please reply with +1.
> > >>>>>
> > >>>>> BRs,
> > >>>>>
> >
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Sebastien,
Yes, maybe your suggestion to create a simple/base crc16 that will be the
base for other crc16 variants could make more sense.
It would be nice to have something similar for crc32 as well.
There are many variations listed in this wikipedia page:
https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Polynomial_representations
BR,
Alan
On Mon, Apr 7, 2025 at 12:29 PM Sebastien Lorquet <se...@lorquet.fr>
wrote:
> Hello,
>
> I understand the need for improvement but I think there is a better
> solution that I am describing at the bottom of this email after the
> rationale.
>
> I will keep my request to not break crc16
>
> Also I explain why changing it is useless.
>
>
> -- why it is useless to change crc16 --
>
> Again, there is NO definition for a single CRC16. There is no CRC16
> standard algorithm. None is better than the other (as a first order
> approximation).
>
> A CRC16 has several parameters and these all must be specified to be
> sure that it's well defined.
>
> Given a polynomial, you can still change the initial value, the final
> xor, and the order of input and output bits.
>
> These parameters are also encoded in a CRC16 and they are rarely mentioned.
>
>
> So "compatibility" with any other platform is a fallacy, because there
> is no standard, the choice of a CRC is just a de facto rule of the
> strongest.
>
> So there is no point to follow linux compatibility or whatever you name
> because these are not, and will never be, recognized standard.
>
> This is not linux's fault. This is not nuttx's fault. this is CRC16
> being badly defined.
>
>
> -- what can be done better --
>
> The best option, to my cryptograpic experience of 15 years, is to
> provide a generic crc16 routine, and implement all variants using
> parameters.
>
> THEN, everywhere you need compatibility, you SPECIFY the crc16 details
> that must be used to ensure compatibility with this particular app.
>
> It can be made compact OR fast, that could also be a build or runtime
> option.
>
>
> This would have my support.
>
> And then, use this to continue to provide the default crc16
> implementation that was decided a long time ago.
>
> Again, I repeat, do NOT break the default crc16. I reckon that it is
> badly defined and maybe unusual, but it's there, and changing it will
> catastrophically break user code that we are not even remotely aware.
>
> Also, I am not suggesting that basing ANY system on the default CRC
> routines of an operating system is a clean design. But it will exist
> nevertheless. so, it must be stable.
>
>
> Here is my proposal:
>
> -define a set of new configurable CRC routines that works like SHA256
> (for example a crc16 context storing parameters, and a
> crc16_generic_init(&context, CRC_PARAMS_WHATEVER), with
> crc16_generic_update, crc16_generic_final
>
> Use this to remplement all existing crc16 you find in nuttx.
>
> Use the new API to implement any new CRC that will need proper and
> strong specified interoperable parameters
>
> This will allow NuttX to claim a clean and well defined CRC16 API.
>
>
> -- conclusion --
>
> Any change you do to change an arbitrary CRC16 by another CRC16 will be
>
> 1 - frustrating
>
> 2 - catastrophic for long term users and unknown code
>
> 3 - not even closer to any standard
>
>
> This is my attempt to suggest a clean and better solution to the crc16
> problem. A simple substitution, with bad words, is just replacing trash
> with another trash. Absolutely useless.
>
> There is a better way.
>
>
> Again and again, dont break the default crc16. Consider it legacy. Keep
> it. Dont break user protocols and mass storage structures.
>
>
> Sebastien
>
>
> On 07/04/2025 17:09, Alan C. Assis wrote:
> > Hi Sebastien,
> >
> > This is a case where compatibility is more important than API stability.
> >
> > New developers are spending a lot of time trying to figure out why
> existing
> > code is not working and end up discovering that the issue is the CRC
> > incompatible with Linux or other OS.
> >
> > If breaking API is an issue, we could propose these modifications to the
> > next major version (version 13).
> >
> > BR,
> >
> > Alan
> >
> >
> > On Mon, Apr 7, 2025 at 11:27 AM Sebastien Lorquet <se...@lorquet.fr>
> > wrote:
> >
> >> Hello,
> >>
> >> No. No way I will EVER be convinced by this change. The default CRC MUST
> >> NOT change.
> >>
> >>
> >> I have been maintaining proprietary code bases for 15 years, and I very
> >> well know this frustration, but the answer is still no. A default
> >> cryptographic algorithm can NOT change.
> >>
> >> All you can do is make sure new code uses your new routines, which are
> >> now appropriately named and form a new stable API.
> >>
> >> But PLEASE keep the API stable.
> >>
> >>
> >> (One-wire has its own crc and if you change it components will stop
> >> working thats all.)
> >>
> >>
> >> CRC used in a "live" system, like a protocol: if you change it, you cant
> >> communicate with other peers of the network
> >>
> >> CRC used in a storage system: You break the on-disk storage structure
> >> and the user looses all their storage.
> >>
> >>
> >> If you change ANY CRC across a release, it results in a catastrophic
> >> failure.
> >>
> >> Please understand: You CANT change a CRC definition if it has been used
> >> ONCE by anyone, even if you are not aware of it.
> >>
> >> And as a reminder, the visible code base is only the tip of the iceberg.
> >>
> >> This breaking change will silently break user code that is already
> >> released.
> >>
> >>
> >> So changing the default crc16 implementation NOW is too much of a
> >> responsibility.
> >>
> >> I refuse this change.
> >>
> >>
> >> As said, I am very welcoming to more CRC algorithms, given they do not
> >> replace the default.
> >>
> >> PLEASE respect this, at least by waiting for another opinion in addition
> >> to mine.
> >>
> >> You cant break protocols and storage systems you are not aware of.
> >>
> >>
> >> I am using strong wording not because I am in a bad mood, but because it
> >> is a really really important point, and I hope I get support from more
> >> project members.
> >>
> >> Again I'm very OK to add several CRC routines, or even a configurable
> >> CRC like crc_init_alg(CRC_TYPE_XMODEM). The CRC table can be generated
> >> dynamically.
> >>
> >> CRC have many different parameters
> >>
> >> -the polynomial
> >>
> >> -the initial value
> >>
> >> -the order of bits from the input
> >>
> >> -the order of bits in the CRC
> >>
> >> -the final inversion of data
> >>
> >> You cant have one crc routine for each. The general case need that much
> >> generality.
> >>
> >> I said please, several times. I BEG you, dont change the default CRC.
> >> Pretty please.
> >>
> >> Best regards,
> >>
> >> Sebastien
> >>
> >>
> >> On 07/04/2025 16:13, chao an wrote:
> >>> Hi, sebastien
> >>>
> >>> I fully understand your concerns, and I agree that changing the default
> >>> algorithm may cause trouble to currently active projects.
> >>> However, I have searched the code for the application scope of crc16 in
> >>> nuttx, and I found that many drivers are using customized CRC-16/IBM
> >>> implementations, which are not capabilities provided by the system.
> >>>
> >>> CRC-16/IBM:
> >>>
> >>> Below drivers implement need CRC-16/IBM support:
> >>>
> >>> 1. 1wire_crc private implementation:
> >>> (poly: 0x8005 (0xA001) initial seed: 0x0000, xor output: 0x0000)
> >>>
> >>
> https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
> >>> 2. spi/uart driver communicate with linux:
> >>>
> >>>
> >>
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi_slave.c#L45-L46
> >>
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi.c#L45-L46
> >>
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_uart.c#L59-L60
> >>> ----------------------------------------
> >>> CRC-16/XMODEM:
> >>>
> >>> CRC-16/XMODEM is currently only used in y/zmodem in nuttx-apps:
> >>>
> >>>
> >>
> https://github.com/apache/nuttx-apps/blob/master/system/ymodem/ymodem.c#L176
> >>
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_state.c#L204
> >>
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_proto.c#L194
> >>
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_send.c#L996
> >>> Furthermore, we found that many communication protocols are using
> >>> CRC-16/IBM implementation.
> >>> In the email, I also explained that this is because popular operating
> >>> systems, such as Linux/OpenBSD/FreeBSD are using CRC-16/IBM by default:
> >>>
> >>> OpenBSD:
> >>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> >>>
> >>> FreeBSD:
> >>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> >>>
> >>> Linux:
> >>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
> >>>
> >>> So I want to convince you further, I think this is better for the
> future
> >>> development of NuttX
> >>>
> >>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月7日周一 21:19写道：
> >>>
> >>>> Hello,
> >>>>
> >>>> Compatibility with other OSes in this domain is dubious.
> >>>>
> >>>> What is the actual need for cross-OS crc16 compatibility?
> >>>>
> >>>> Self-compatibilty is much more important. What is a non volatile
> storage
> >>>> structure was created by the old CRC (old release) is checked with the
> >>>> new CRC?
> >>>>
> >>>> This will be an immediate fatal error with potentially grave
> >> consequences.
> >>>> I am FULLY AGAINST this change.
> >>>>
> >>>> It MUST NOT PROCEED.
> >>>>
> >>>> I still think you can introduce additional routines to compute other
> CRC
> >>>> variations, but the default crc MUST DEFINITELY NOT CHANGE.
> >>>>
> >>>> Use the new routines in a wrapper in your code, but DO NOT CHANGE the
> >>>> default CRC algorithm
> >>>>
> >>>> This is an ABSOLUTELY CRITICAL ISSUE!
> >>>>
> >>>> -1
> >>>>
> >>>> Sebastien
> >>>>
> >>>>
> >>>> On 07/04/2025 10:35, chao an wrote:
> >>>>> Hi Community,
> >>>>>
> >>>>> I plan to switch the default CRC16 algorithm directory of NuttX from
> >>>>> CRC-16/XMODEM to CRC-16/IBM:
> >>>>> https://github.com/apache/nuttx/pull/16147
> >>>>>
> >>>>> CRC-16/XMODEM as the default implementation has significant
> >> limitations,
> >>>>> especially when communicating with popular operating systems and it
> >> comes
> >>>>> to CRC encryption verification, the algorithm needs to be switched.
> >>>>>
> >>>>> I have conducted research on POSIX-compatible operating systems, and
> >>>> almost
> >>>>> all of them use CRC-16/IBM as the default implementation:
> >>>>>
> >>>>> OpenBSD:
> >>>>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> >>>>>
> >>>>> FreeBSD:
> >>>>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> >>>>>
> >>>>> Linux:
> >>>>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
> >>>>>
> >>>>> So I need your vote here:
> >>>>> If you prefer CRC-16/XMODEM, please reply with -1.
> >>>>> If you recommend CRC-16/IBM, please reply with +1.
> >>>>>
> >>>>> BRs,
> >>>>>
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
I understand the need for improvement but I think there is a better
solution that I am describing at the bottom of this email after the
rationale.
I will keep my request to not break crc16
Also I explain why changing it is useless.
-- why it is useless to change crc16 --
Again, there is NO definition for a single CRC16. There is no CRC16
standard algorithm. None is better than the other (as a first order
approximation).
A CRC16 has several parameters and these all must be specified to be
sure that it's well defined.
Given a polynomial, you can still change the initial value, the final
xor, and the order of input and output bits.
These parameters are also encoded in a CRC16 and they are rarely mentioned.
So "compatibility" with any other platform is a fallacy, because there
is no standard, the choice of a CRC is just a de facto rule of the
strongest.
So there is no point to follow linux compatibility or whatever you name
because these are not, and will never be, recognized standard.
This is not linux's fault. This is not nuttx's fault. this is CRC16
being badly defined.
-- what can be done better --
The best option, to my cryptograpic experience of 15 years, is to
provide a generic crc16 routine, and implement all variants using
parameters.
THEN, everywhere you need compatibility, you SPECIFY the crc16 details
that must be used to ensure compatibility with this particular app.
It can be made compact OR fast, that could also be a build or runtime
option.
This would have my support.
And then, use this to continue to provide the default crc16
implementation that was decided a long time ago.
Again, I repeat, do NOT break the default crc16. I reckon that it is
badly defined and maybe unusual, but it's there, and changing it will
catastrophically break user code that we are not even remotely aware.
Also, I am not suggesting that basing ANY system on the default CRC
routines of an operating system is a clean design. But it will exist
nevertheless. so, it must be stable.
Here is my proposal:
-define a set of new configurable CRC routines that works like SHA256
(for example a crc16 context storing parameters, and a
crc16_generic_init(&context, CRC_PARAMS_WHATEVER), with
crc16_generic_update, crc16_generic_final
Use this to remplement all existing crc16 you find in nuttx.
Use the new API to implement any new CRC that will need proper and
strong specified interoperable parameters
This will allow NuttX to claim a clean and well defined CRC16 API.
-- conclusion --
Any change you do to change an arbitrary CRC16 by another CRC16 will be
1 - frustrating
2 - catastrophic for long term users and unknown code
3 - not even closer to any standard
This is my attempt to suggest a clean and better solution to the crc16
problem. A simple substitution, with bad words, is just replacing trash
with another trash. Absolutely useless.
There is a better way.
Again and again, dont break the default crc16. Consider it legacy. Keep
it. Dont break user protocols and mass storage structures.
Sebastien
On 07/04/2025 17:09, Alan C. Assis wrote:
> Hi Sebastien,
>
> This is a case where compatibility is more important than API stability.
>
> New developers are spending a lot of time trying to figure out why existing
> code is not working and end up discovering that the issue is the CRC
> incompatible with Linux or other OS.
>
> If breaking API is an issue, we could propose these modifications to the
> next major version (version 13).
>
> BR,
>
> Alan
>
>
> On Mon, Apr 7, 2025 at 11:27 AM Sebastien Lorquet <se...@lorquet.fr>
> wrote:
>
>> Hello,
>>
>> No. No way I will EVER be convinced by this change. The default CRC MUST
>> NOT change.
>>
>>
>> I have been maintaining proprietary code bases for 15 years, and I very
>> well know this frustration, but the answer is still no. A default
>> cryptographic algorithm can NOT change.
>>
>> All you can do is make sure new code uses your new routines, which are
>> now appropriately named and form a new stable API.
>>
>> But PLEASE keep the API stable.
>>
>>
>> (One-wire has its own crc and if you change it components will stop
>> working thats all.)
>>
>>
>> CRC used in a "live" system, like a protocol: if you change it, you cant
>> communicate with other peers of the network
>>
>> CRC used in a storage system: You break the on-disk storage structure
>> and the user looses all their storage.
>>
>>
>> If you change ANY CRC across a release, it results in a catastrophic
>> failure.
>>
>> Please understand: You CANT change a CRC definition if it has been used
>> ONCE by anyone, even if you are not aware of it.
>>
>> And as a reminder, the visible code base is only the tip of the iceberg.
>>
>> This breaking change will silently break user code that is already
>> released.
>>
>>
>> So changing the default crc16 implementation NOW is too much of a
>> responsibility.
>>
>> I refuse this change.
>>
>>
>> As said, I am very welcoming to more CRC algorithms, given they do not
>> replace the default.
>>
>> PLEASE respect this, at least by waiting for another opinion in addition
>> to mine.
>>
>> You cant break protocols and storage systems you are not aware of.
>>
>>
>> I am using strong wording not because I am in a bad mood, but because it
>> is a really really important point, and I hope I get support from more
>> project members.
>>
>> Again I'm very OK to add several CRC routines, or even a configurable
>> CRC like crc_init_alg(CRC_TYPE_XMODEM). The CRC table can be generated
>> dynamically.
>>
>> CRC have many different parameters
>>
>> -the polynomial
>>
>> -the initial value
>>
>> -the order of bits from the input
>>
>> -the order of bits in the CRC
>>
>> -the final inversion of data
>>
>> You cant have one crc routine for each. The general case need that much
>> generality.
>>
>> I said please, several times. I BEG you, dont change the default CRC.
>> Pretty please.
>>
>> Best regards,
>>
>> Sebastien
>>
>>
>> On 07/04/2025 16:13, chao an wrote:
>>> Hi, sebastien
>>>
>>> I fully understand your concerns, and I agree that changing the default
>>> algorithm may cause trouble to currently active projects.
>>> However, I have searched the code for the application scope of crc16 in
>>> nuttx, and I found that many drivers are using customized CRC-16/IBM
>>> implementations, which are not capabilities provided by the system.
>>>
>>> CRC-16/IBM:
>>>
>>> Below drivers implement need CRC-16/IBM support:
>>>
>>> 1. 1wire_crc private implementation:
>>> (poly: 0x8005 (0xA001) initial seed: 0x0000, xor output: 0x0000)
>>>
>> https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
>>> 2. spi/uart driver communicate with linux:
>>>
>>>
>> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi_slave.c#L45-L46
>> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi.c#L45-L46
>> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_uart.c#L59-L60
>>> ----------------------------------------
>>> CRC-16/XMODEM:
>>>
>>> CRC-16/XMODEM is currently only used in y/zmodem in nuttx-apps:
>>>
>>>
>> https://github.com/apache/nuttx-apps/blob/master/system/ymodem/ymodem.c#L176
>> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_state.c#L204
>> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_proto.c#L194
>> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_send.c#L996
>>> Furthermore, we found that many communication protocols are using
>>> CRC-16/IBM implementation.
>>> In the email, I also explained that this is because popular operating
>>> systems, such as Linux/OpenBSD/FreeBSD are using CRC-16/IBM by default:
>>>
>>> OpenBSD:
>>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
>>>
>>> FreeBSD:
>>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
>>>
>>> Linux:
>>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
>>>
>>> So I want to convince you further, I think this is better for the future
>>> development of NuttX
>>>
>>> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月7日周一 21:19写道：
>>>
>>>> Hello,
>>>>
>>>> Compatibility with other OSes in this domain is dubious.
>>>>
>>>> What is the actual need for cross-OS crc16 compatibility?
>>>>
>>>> Self-compatibilty is much more important. What is a non volatile storage
>>>> structure was created by the old CRC (old release) is checked with the
>>>> new CRC?
>>>>
>>>> This will be an immediate fatal error with potentially grave
>> consequences.
>>>> I am FULLY AGAINST this change.
>>>>
>>>> It MUST NOT PROCEED.
>>>>
>>>> I still think you can introduce additional routines to compute other CRC
>>>> variations, but the default crc MUST DEFINITELY NOT CHANGE.
>>>>
>>>> Use the new routines in a wrapper in your code, but DO NOT CHANGE the
>>>> default CRC algorithm
>>>>
>>>> This is an ABSOLUTELY CRITICAL ISSUE!
>>>>
>>>> -1
>>>>
>>>> Sebastien
>>>>
>>>>
>>>> On 07/04/2025 10:35, chao an wrote:
>>>>> Hi Community,
>>>>>
>>>>> I plan to switch the default CRC16 algorithm directory of NuttX from
>>>>> CRC-16/XMODEM to CRC-16/IBM:
>>>>> https://github.com/apache/nuttx/pull/16147
>>>>>
>>>>> CRC-16/XMODEM as the default implementation has significant
>> limitations,
>>>>> especially when communicating with popular operating systems and it
>> comes
>>>>> to CRC encryption verification, the algorithm needs to be switched.
>>>>>
>>>>> I have conducted research on POSIX-compatible operating systems, and
>>>> almost
>>>>> all of them use CRC-16/IBM as the default implementation:
>>>>>
>>>>> OpenBSD:
>>>>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
>>>>>
>>>>> FreeBSD:
>>>>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
>>>>>
>>>>> Linux:
>>>>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
>>>>>
>>>>> So I need your vote here:
>>>>> If you prefer CRC-16/XMODEM, please reply with -1.
>>>>> If you recommend CRC-16/IBM, please reply with +1.
>>>>>
>>>>> BRs,
>>>>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Sebastien,
This is a case where compatibility is more important than API stability.
New developers are spending a lot of time trying to figure out why existing
code is not working and end up discovering that the issue is the CRC
incompatible with Linux or other OS.
If breaking API is an issue, we could propose these modifications to the
next major version (version 13).
BR,
Alan
On Mon, Apr 7, 2025 at 11:27 AM Sebastien Lorquet <se...@lorquet.fr>
wrote:
> Hello,
>
> No. No way I will EVER be convinced by this change. The default CRC MUST
> NOT change.
>
>
> I have been maintaining proprietary code bases for 15 years, and I very
> well know this frustration, but the answer is still no. A default
> cryptographic algorithm can NOT change.
>
> All you can do is make sure new code uses your new routines, which are
> now appropriately named and form a new stable API.
>
> But PLEASE keep the API stable.
>
>
> (One-wire has its own crc and if you change it components will stop
> working thats all.)
>
>
> CRC used in a "live" system, like a protocol: if you change it, you cant
> communicate with other peers of the network
>
> CRC used in a storage system: You break the on-disk storage structure
> and the user looses all their storage.
>
>
> If you change ANY CRC across a release, it results in a catastrophic
> failure.
>
> Please understand: You CANT change a CRC definition if it has been used
> ONCE by anyone, even if you are not aware of it.
>
> And as a reminder, the visible code base is only the tip of the iceberg.
>
> This breaking change will silently break user code that is already
> released.
>
>
> So changing the default crc16 implementation NOW is too much of a
> responsibility.
>
> I refuse this change.
>
>
> As said, I am very welcoming to more CRC algorithms, given they do not
> replace the default.
>
> PLEASE respect this, at least by waiting for another opinion in addition
> to mine.
>
> You cant break protocols and storage systems you are not aware of.
>
>
> I am using strong wording not because I am in a bad mood, but because it
> is a really really important point, and I hope I get support from more
> project members.
>
> Again I'm very OK to add several CRC routines, or even a configurable
> CRC like crc_init_alg(CRC_TYPE_XMODEM). The CRC table can be generated
> dynamically.
>
> CRC have many different parameters
>
> -the polynomial
>
> -the initial value
>
> -the order of bits from the input
>
> -the order of bits in the CRC
>
> -the final inversion of data
>
> You cant have one crc routine for each. The general case need that much
> generality.
>
> I said please, several times. I BEG you, dont change the default CRC.
> Pretty please.
>
> Best regards,
>
> Sebastien
>
>
> On 07/04/2025 16:13, chao an wrote:
> > Hi, sebastien
> >
> > I fully understand your concerns, and I agree that changing the default
> > algorithm may cause trouble to currently active projects.
> > However, I have searched the code for the application scope of crc16 in
> > nuttx, and I found that many drivers are using customized CRC-16/IBM
> > implementations, which are not capabilities provided by the system.
> >
> > CRC-16/IBM:
> >
> > Below drivers implement need CRC-16/IBM support:
> >
> > 1. 1wire_crc private implementation:
> > (poly: 0x8005 (0xA001) initial seed: 0x0000, xor output: 0x0000)
> >
> https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
> >
> > 2. spi/uart driver communicate with linux:
> >
> >
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi_slave.c#L45-L46
> >
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi.c#L45-L46
> >
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_uart.c#L59-L60
> >
> > ----------------------------------------
> > CRC-16/XMODEM:
> >
> > CRC-16/XMODEM is currently only used in y/zmodem in nuttx-apps:
> >
> >
> https://github.com/apache/nuttx-apps/blob/master/system/ymodem/ymodem.c#L176
> >
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_state.c#L204
> >
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_proto.c#L194
> >
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_send.c#L996
> >
> > Furthermore, we found that many communication protocols are using
> > CRC-16/IBM implementation.
> > In the email, I also explained that this is because popular operating
> > systems, such as Linux/OpenBSD/FreeBSD are using CRC-16/IBM by default:
> >
> > OpenBSD:
> > https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> >
> > FreeBSD:
> > https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> >
> > Linux:
> > https://github.com/torvalds/linux/blob/master/lib/crc16.c
> >
> > So I want to convince you further, I think this is better for the future
> > development of NuttX
> >
> > Sebastien Lorquet <se...@lorquet.fr> 于2025年4月7日周一 21:19写道：
> >
> >> Hello,
> >>
> >> Compatibility with other OSes in this domain is dubious.
> >>
> >> What is the actual need for cross-OS crc16 compatibility?
> >>
> >> Self-compatibilty is much more important. What is a non volatile storage
> >> structure was created by the old CRC (old release) is checked with the
> >> new CRC?
> >>
> >> This will be an immediate fatal error with potentially grave
> consequences.
> >>
> >> I am FULLY AGAINST this change.
> >>
> >> It MUST NOT PROCEED.
> >>
> >> I still think you can introduce additional routines to compute other CRC
> >> variations, but the default crc MUST DEFINITELY NOT CHANGE.
> >>
> >> Use the new routines in a wrapper in your code, but DO NOT CHANGE the
> >> default CRC algorithm
> >>
> >> This is an ABSOLUTELY CRITICAL ISSUE!
> >>
> >> -1
> >>
> >> Sebastien
> >>
> >>
> >> On 07/04/2025 10:35, chao an wrote:
> >>> Hi Community,
> >>>
> >>> I plan to switch the default CRC16 algorithm directory of NuttX from
> >>> CRC-16/XMODEM to CRC-16/IBM:
> >>> https://github.com/apache/nuttx/pull/16147
> >>>
> >>> CRC-16/XMODEM as the default implementation has significant
> limitations,
> >>> especially when communicating with popular operating systems and it
> comes
> >>> to CRC encryption verification, the algorithm needs to be switched.
> >>>
> >>> I have conducted research on POSIX-compatible operating systems, and
> >> almost
> >>> all of them use CRC-16/IBM as the default implementation:
> >>>
> >>> OpenBSD:
> >>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> >>>
> >>> FreeBSD:
> >>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> >>>
> >>> Linux:
> >>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
> >>>
> >>> So I need your vote here:
> >>> If you prefer CRC-16/XMODEM, please reply with -1.
> >>> If you recommend CRC-16/IBM, please reply with +1.
> >>>
> >>> BRs,
> >>>
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
No. No way I will EVER be convinced by this change. The default CRC MUST
NOT change.
I have been maintaining proprietary code bases for 15 years, and I very
well know this frustration, but the answer is still no. A default
cryptographic algorithm can NOT change.
All you can do is make sure new code uses your new routines, which are
now appropriately named and form a new stable API.
But PLEASE keep the API stable.
(One-wire has its own crc and if you change it components will stop
working thats all.)
CRC used in a "live" system, like a protocol: if you change it, you cant
communicate with other peers of the network
CRC used in a storage system: You break the on-disk storage structure
and the user looses all their storage.
If you change ANY CRC across a release, it results in a catastrophic
failure.
Please understand: You CANT change a CRC definition if it has been used
ONCE by anyone, even if you are not aware of it.
And as a reminder, the visible code base is only the tip of the iceberg.
This breaking change will silently break user code that is already released.
So changing the default crc16 implementation NOW is too much of a
responsibility.
I refuse this change.
As said, I am very welcoming to more CRC algorithms, given they do not
replace the default.
PLEASE respect this, at least by waiting for another opinion in addition
to mine.
You cant break protocols and storage systems you are not aware of.
I am using strong wording not because I am in a bad mood, but because it
is a really really important point, and I hope I get support from more
project members.
Again I'm very OK to add several CRC routines, or even a configurable
CRC like crc_init_alg(CRC_TYPE_XMODEM). The CRC table can be generated
dynamically.
CRC have many different parameters
-the polynomial
-the initial value
-the order of bits from the input
-the order of bits in the CRC
-the final inversion of data
You cant have one crc routine for each. The general case need that much
generality.
I said please, several times. I BEG you, dont change the default CRC.
Pretty please.
Best regards,
Sebastien
On 07/04/2025 16:13, chao an wrote:
> Hi, sebastien
>
> I fully understand your concerns, and I agree that changing the default
> algorithm may cause trouble to currently active projects.
> However, I have searched the code for the application scope of crc16 in
> nuttx, and I found that many drivers are using customized CRC-16/IBM
> implementations, which are not capabilities provided by the system.
>
> CRC-16/IBM:
>
> Below drivers implement need CRC-16/IBM support:
>
> 1. 1wire_crc private implementation:
> (poly: 0x8005 (0xA001) initial seed: 0x0000, xor output: 0x0000)
> https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
>
> 2. spi/uart driver communicate with linux:
>
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi_slave.c#L45-L46
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi.c#L45-L46
> https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_uart.c#L59-L60
>
> ----------------------------------------
> CRC-16/XMODEM:
>
> CRC-16/XMODEM is currently only used in y/zmodem in nuttx-apps:
>
> https://github.com/apache/nuttx-apps/blob/master/system/ymodem/ymodem.c#L176
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_state.c#L204
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_proto.c#L194
> https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_send.c#L996
>
> Furthermore, we found that many communication protocols are using
> CRC-16/IBM implementation.
> In the email, I also explained that this is because popular operating
> systems, such as Linux/OpenBSD/FreeBSD are using CRC-16/IBM by default:
>
> OpenBSD:
> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
>
> FreeBSD:
> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
>
> Linux:
> https://github.com/torvalds/linux/blob/master/lib/crc16.c
>
> So I want to convince you further, I think this is better for the future
> development of NuttX
>
> Sebastien Lorquet <se...@lorquet.fr> 于2025年4月7日周一 21:19写道：
>
>> Hello,
>>
>> Compatibility with other OSes in this domain is dubious.
>>
>> What is the actual need for cross-OS crc16 compatibility?
>>
>> Self-compatibilty is much more important. What is a non volatile storage
>> structure was created by the old CRC (old release) is checked with the
>> new CRC?
>>
>> This will be an immediate fatal error with potentially grave consequences.
>>
>> I am FULLY AGAINST this change.
>>
>> It MUST NOT PROCEED.
>>
>> I still think you can introduce additional routines to compute other CRC
>> variations, but the default crc MUST DEFINITELY NOT CHANGE.
>>
>> Use the new routines in a wrapper in your code, but DO NOT CHANGE the
>> default CRC algorithm
>>
>> This is an ABSOLUTELY CRITICAL ISSUE!
>>
>> -1
>>
>> Sebastien
>>
>>
>> On 07/04/2025 10:35, chao an wrote:
>>> Hi Community,
>>>
>>> I plan to switch the default CRC16 algorithm directory of NuttX from
>>> CRC-16/XMODEM to CRC-16/IBM:
>>> https://github.com/apache/nuttx/pull/16147
>>>
>>> CRC-16/XMODEM as the default implementation has significant limitations,
>>> especially when communicating with popular operating systems and it comes
>>> to CRC encryption verification, the algorithm needs to be switched.
>>>
>>> I have conducted research on POSIX-compatible operating systems, and
>> almost
>>> all of them use CRC-16/IBM as the default implementation:
>>>
>>> OpenBSD:
>>> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
>>>
>>> FreeBSD:
>>> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
>>>
>>> Linux:
>>> https://github.com/torvalds/linux/blob/master/lib/crc16.c
>>>
>>> So I need your vote here:
>>> If you prefer CRC-16/XMODEM, please reply with -1.
>>> If you recommend CRC-16/IBM, please reply with +1.
>>>
>>> BRs,
>>>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by chao an <ma...@gmail.com>.
Hi, sebastien
I fully understand your concerns, and I agree that changing the default
algorithm may cause trouble to currently active projects.
However, I have searched the code for the application scope of crc16 in
nuttx, and I found that many drivers are using customized CRC-16/IBM
implementations, which are not capabilities provided by the system.
CRC-16/IBM:
Below drivers implement need CRC-16/IBM support:
1. 1wire_crc private implementation:
(poly: 0x8005 (0xA001) initial seed: 0x0000, xor output: 0x0000)
https://github.com/apache/nuttx/blob/master/drivers/1wire/1wire_crc.c#L73-L98
2. spi/uart driver communicate with linux:
https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi_slave.c#L45-L46
https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_spi.c#L45-L46
https://github.com/apache/nuttx/blob/master/drivers/rpmsg/rpmsg_port_uart.c#L59-L60
----------------------------------------
CRC-16/XMODEM:
CRC-16/XMODEM is currently only used in y/zmodem in nuttx-apps:
https://github.com/apache/nuttx-apps/blob/master/system/ymodem/ymodem.c#L176
https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_state.c#L204
https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_proto.c#L194
https://github.com/apache/nuttx-apps/blob/master/system/zmodem/zm_send.c#L996
Furthermore, we found that many communication protocols are using
CRC-16/IBM implementation.
In the email, I also explained that this is because popular operating
systems, such as Linux/OpenBSD/FreeBSD are using CRC-16/IBM by default:
OpenBSD:
https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
FreeBSD:
https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
Linux:
https://github.com/torvalds/linux/blob/master/lib/crc16.c
So I want to convince you further, I think this is better for the future
development of NuttX
Sebastien Lorquet <se...@lorquet.fr> 于2025年4月7日周一 21:19写道：
> Hello,
>
> Compatibility with other OSes in this domain is dubious.
>
> What is the actual need for cross-OS crc16 compatibility?
>
> Self-compatibilty is much more important. What is a non volatile storage
> structure was created by the old CRC (old release) is checked with the
> new CRC?
>
> This will be an immediate fatal error with potentially grave consequences.
>
> I am FULLY AGAINST this change.
>
> It MUST NOT PROCEED.
>
> I still think you can introduce additional routines to compute other CRC
> variations, but the default crc MUST DEFINITELY NOT CHANGE.
>
> Use the new routines in a wrapper in your code, but DO NOT CHANGE the
> default CRC algorithm
>
> This is an ABSOLUTELY CRITICAL ISSUE!
>
> -1
>
> Sebastien
>
>
> On 07/04/2025 10:35, chao an wrote:
> > Hi Community,
> >
> > I plan to switch the default CRC16 algorithm directory of NuttX from
> > CRC-16/XMODEM to CRC-16/IBM:
> > https://github.com/apache/nuttx/pull/16147
> >
> > CRC-16/XMODEM as the default implementation has significant limitations,
> > especially when communicating with popular operating systems and it comes
> > to CRC encryption verification, the algorithm needs to be switched.
> >
> > I have conducted research on POSIX-compatible operating systems, and
> almost
> > all of them use CRC-16/IBM as the default implementation:
> >
> > OpenBSD:
> > https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
> >
> > FreeBSD:
> > https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
> >
> > Linux:
> > https://github.com/torvalds/linux/blob/master/lib/crc16.c
> >
> > So I need your vote here:
> > If you prefer CRC-16/XMODEM, please reply with -1.
> > If you recommend CRC-16/IBM, please reply with +1.
> >
> > BRs,
> >
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
Compatibility with other OSes in this domain is dubious.
What is the actual need for cross-OS crc16 compatibility?
Self-compatibilty is much more important. What is a non volatile storage
structure was created by the old CRC (old release) is checked with the
new CRC?
This will be an immediate fatal error with potentially grave consequences.
I am FULLY AGAINST this change.
It MUST NOT PROCEED.
I still think you can introduce additional routines to compute other CRC
variations, but the default crc MUST DEFINITELY NOT CHANGE.
Use the new routines in a wrapper in your code, but DO NOT CHANGE the
default CRC algorithm
This is an ABSOLUTELY CRITICAL ISSUE!
-1
Sebastien
On 07/04/2025 10:35, chao an wrote:
> Hi Community,
>
> I plan to switch the default CRC16 algorithm directory of NuttX from
> CRC-16/XMODEM to CRC-16/IBM:
> https://github.com/apache/nuttx/pull/16147
>
> CRC-16/XMODEM as the default implementation has significant limitations,
> especially when communicating with popular operating systems and it comes
> to CRC encryption verification, the algorithm needs to be switched.
>
> I have conducted research on POSIX-compatible operating systems, and almost
> all of them use CRC-16/IBM as the default implementation:
>
> OpenBSD:
> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
>
> FreeBSD:
> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
>
> Linux:
> https://github.com/torvalds/linux/blob/master/lib/crc16.c
>
> So I need your vote here:
> If you prefer CRC-16/XMODEM, please reply with -1.
> If you recommend CRC-16/IBM, please reply with +1.
>
> BRs,
>
Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM
Posted by Lwazi Dube <lw...@gmail.com>.
+1
On Mon, 7 Apr 2025 at 04:58, chao an <ma...@gmail.com> wrote:
> Hi Community,
>
> I plan to switch the default CRC16 algorithm directory of NuttX from
> CRC-16/XMODEM to CRC-16/IBM:
> https://github.com/apache/nuttx/pull/16147
>
> CRC-16/XMODEM as the default implementation has significant limitations,
> especially when communicating with popular operating systems and it comes
> to CRC encryption verification, the algorithm needs to be switched.
>
> I have conducted research on POSIX-compatible operating systems, and almost
> all of them use CRC-16/IBM as the default implementation:
>
> OpenBSD:
> https://github.com/openbsd/src/blob/master/sys/lib/libkern/crc16.h
>
> FreeBSD:
> https://github.com/freebsd/freebsd-src/blob/main/sys/libkern/crc16.c
>
> Linux:
> https://github.com/torvalds/linux/blob/master/lib/crc16.c
>
> So I need your vote here:
> If you prefer CRC-16/XMODEM, please reply with -1.
> If you recommend CRC-16/IBM, please reply with +1.
>
> BRs,
>