On Mon, 7 Apr 2025 at 18:21, Nathan Hartman
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
>
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
-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
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
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
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 wrote:
> There was no diatribe this time. I had the same single argument the
> whole time: for long term self compatibility, we can not c
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
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 v
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 re
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
wrote:
> Yes.
>
> This function was not carefu
On Wed, 9 Apr 2025 at 03:43, Sebastien Lorquet 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 deve
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 ca
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
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
I like your second option, so could we remove the implementation of both
crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
BRs,
Sebastien Lorquet 于2025年4月9日周三 16:00写道：
> Hello,
>
> once again, the number of usage is unimportant and irrelevant.
>
> The ONLY thing that matters
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 y
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.
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
On Wed, Apr 9, 2025 at 3:45 AM chao an wrote:
> > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube 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
> > > im
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 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
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 expe
>
>
> > 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
> >
On Tue, 8 Apr 2025 at 13:32, Xiang Xiao wrote:
> On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube wrote:
>
> > On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet
> > wrote:
> >
> > > Hello,
> > >
> > > Nathan proposal to have a kconfig, with a default to the historical
> > > algorithm, is a good solution.
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 wrote:
> +1 regarding Tomek's comments.
>
> I'm all for documenting the current semantics of CRCs used by Nuttx and
> ex
On Tue, 8 Apr 2025 at 14:49, Xiang Xiao wrote:
> On Wed, Apr 9, 2025 at 2:02 AM Lwazi Dube wrote:
>
> > On Tue, 8 Apr 2025 at 13:32, Xiang Xiao
> wrote:
> >
> > > On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube wrote:
> > >
> > > > On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet >
> > > > 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 h
On Wed, Apr 9, 2025 at 2:02 AM Lwazi Dube wrote:
> On Tue, 8 Apr 2025 at 13:32, Xiang Xiao wrote:
>
> > On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube wrote:
> >
> > > On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > Nathan proposal to have a kconfig,
On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube 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.
On Wed, Apr 9, 2025 at 1:16 AM Lwazi Dube wrote:
> On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet
> 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
On Tue, 8 Apr 2025 at 05:23, Sebastien Lorquet 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)
retur
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
+1 if there is backwards compatibility and proper documentation
On Tue, 8 Apr 2025, 04:00 chao an, 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
>
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
crc16c
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.
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
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/Cycli
-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,
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, the
+1
On Mon, 7 Apr 2025 at 04:58, 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,
> espe
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
implementatio
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
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 m
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
42 matches
Mail list logo
