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 <sebast...@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 <sebast...@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, > >>> >
