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 <acas...@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 <hartman.nat...@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 <magicd...@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 <sebast...@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 <sebast...@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 <magicd...@gmail.com> wrote: >>>>>> > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lwa...@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
