wangchdo commented on PR #17556: URL: https://github.com/apache/nuttx/pull/17556#issuecomment-3673981282
> > > > Guys, instead of compete to see who implemented first or which implementation has best performance, it is better to work together to get best part of each implementation and contribute a better solution to NuttX. > > > > > > > > > > > > > > > > > > > > This features is very important to everyone using NuttX (not only LiAuto or Xiaomi). > > > > > > > > > > > > > > > > > > > > @Fix-Point and @anchao please align between you both how to integrate it in a way that the best interest is the project quality, not individual ego. > > > > > > > > > I agree. > > > The main problem is that NuttX should consider all application scenarios, including IoT devices, automotive, multi-core embedded devices, and etc. But, @wangchdo only considered his `tc397` board in his design, adding so many ugly workarounds to NuttX kernel just to fix the Tricore timer issues. I believe such code and implementation should be removed later. > > > I believe the community should encourage better implementations, rather than more meaningless, performance-inefficient, and product-specific implementations. > > > For the HRtimer, I believe my implementation is better in performance, composability and general. So I insist this hrtimer is a better implementation, not just "a optimization for their hrtimer". I suggest they added optimization on this implementation, that's my opinion. > > > By the way, It is so funny that every time @wangchdo claims all I have done looks like his work, although these are completely different things. > > > > @xiaoxiang781216 @Fix-Point This looks similar to the hrtimer driver I planned to add in my PR #17065, which was intended to provide access to the hardware timer count. > > > > > > > > > > > > > > > > > > > > However, @xiaoxiang781216 mentioned in that PR that adding a new timer driver is not allowed in NuttX, so I removed the implementation, and reimplemented the sched/hrtimer based on the exsiting timer driver. > > > > > > > > > > > > > > > > > > > > Your PR to introcude ClockDevice makes me feel confused about the criteria for what kind of functionality is acceptable to add to NuttX... > > > > > > I don't think it is polite to attack other personally, i am just a personal contributor, not a team working on nuttx, and contribute PRs using my personal time, and they got merged only when are approved by committers or PMC. > > If you think they are ugly, inefficient or meaningless,you are welcome to provide comments > > I have merged more than 110 commits (timer or tricore arch related are only a small part of them) without receiving any of your comments > > I have no intention of arguing with anyone. My only hope is for NuttX to become faster and more reliable—nothing more. I respect and understand all community developers because it is their efforts that drive the progress of NuttX. > > My concern is that you have repeatedly accused me, without any evidence, of making my implementation similar to yours and implied that I used your ideas. **This is deeply disrespectful to me**. Therefore, I would like to clarify a few facts to show that I did not use your ideas at all, hoping to clear up any misunderstandings. > > 1. Timeline: > At the Apache NuttX International Workshop on October 16, 2025, I delivered a presentation titled "CLOCKDEVICE: New Timer Driver Abstraction for NuttX." In the architecture diagram on page 9, I **had already included hrtimer in the plan**. The PPT was completed and reviewed as early as September. > By **mid-September, the concurrent state machine for HRtimer had already been designed**, though the interface details were not yet finalized. > **In October, after referencing the Linux kernel's HRTimer, I drafted a design document, refined the HRTimer design, and discussed it internally with colleagues**. From September to November, I was fully occupied with developing, validating, and upstreaming the CLOCKDEVICE driver to the community, leaving me no time to complete the full implementation of hrtimer, which remained in an early prototype stage. Collegues informed me that someone in the community was working on hrtimer, but due to my busy schedule, I never looked into it—this was my mistake. > On December 1st, I provided a relatively complete implementation of hrtimer, which underwent multiple rounds of internal review and improvements. On December 15th, during a WeChat conversation, I shared my design with you and pointed out issues in your design. To my confusion, you reacted with anger, accusing me of copying your ideas. Prior to this, I had never communicated with you or seen your implementation. **Accusing someone of copying ideas is a serious allegation, and it deeply hurt my self-respect**. It is you who suggested that I submit my code to the community for evaluation. I agreed with this suggestion and submitted the PR on December 18th. > 2. I only wish to engage in technical discussions. Your hrtimer implementation has the following issues, which cannot be fixed with minor modifications: > > * **Completely unusable for users**: This is a fundamental flaw in the state machine design and cannot be resolved with minor changes. [[BUG] Unusable HRTimer #17567](https://github.com/apache/nuttx/issues/17567) > * **Untested for SMP**: Its reliability on SMP platforms is questionable. > * **Lacks detailed design documentation and clear state transition diagrams**: ISO 26262 functional safety standards require a structured diagram approach, and state machine designs must be provided for modules. > * **No performance test data**: You have not provided any data demonstrating the impact on system execution time. > > I believe it is entirely reasonable to replace your implementation with a better one (or refactor it, if that term makes you feel more comfortable). > > I do not understand why @anchao has been siding with you while ignoring the facts, which has left me disappointed with the community. You should use `hrtimer_cancel_sync `api if you want to make sure hrtimer_cancel is successful, please check the documentation: .. c:function:: int hrtimer_cancel_sync(FAR hrtimer_t *hrtimer) Cancel a high-resolution timer and wait synchronously until the timer becomes inactive. This function first calls hrtimer_cancel() to request cancellation of the timer. If the timer callback is currently executing, this function will wait until the callback has completed and the timer state has transitioned to HRTIMER_STATE_INACTIVE. This function may sleep and must not be called from interrupt context. :param hrtimer: Timer instance to cancel :return: ``OK`` on success; negated errno on failure. **POSIX Compatibility:** This is a NON-POSIX interface. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
