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 <magicd...@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 <lwa...@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 <peter.bar...@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 <lwa...@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.bar...@gmail.com > > > > > > > > >
