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 > > > > >
