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