Fix-Point commented on PR #17556:
URL: https://github.com/apache/nuttx/pull/17556#issuecomment-3673824463
> > > 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**. You 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.
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.
--
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]
