Tomek,
Regarding this pull request:I'm trying to test it quickly on our
STM32F427 based board, I cant pull the jtag probe before monday.
I have checked out the apache_8 branch of
https://github.com/hujun260/nuttx/tree/apache_8
-the tools/process_config.sh file is still broken, I could work
On Wed, Feb 5, 2025 at 12:18 PM hujun260 wrote:
> I reverted the relevant changes.
> https://github.com/apache/nuttx/pull/15767
Sebastien, could you please verify this fix? That change seems to
impact you directly?
Note this is not a full revert, some optimizations are left in place.
Until reso
On Thu, Feb 6, 2025 at 2:16 AM Nathan Hartman wrote:
> Even though there are some problems, I am glad that the community is
> actively addressing them and that we are discussing how to improve in the
> future.
Exactly :-) When doing R&D you need thousands of failures to get
something working.. bu
Thank you guys for bringing this discussion on the mailing list! We
really should first discuss any breaking change on the list long
enough until everyone is happy.. and we are sure not to break anything
:-)
Suggestions to verify in depth on a real world hardware any subtle
issue will be soon our
Even though there are some problems, I am glad that the community is
actively addressing them and that we are discussing how to improve in the
future.
I can't offer advice on the spinlock question at this time because I
haven't studied it, but when I ship my current project I should have more
time
Thanks everyone for bringing light to this discussion!
Well, I support reverting the introduced changes as in
https://github.com/apache/nuttx/pull/15767 and continue working on the
https://github.com/apache/nuttx/pull/15705
In summary, I prefer to use Option 1:
*Option 1:*
>
> spin_lock:
Hello,
On 05/02/2025 15:43, chao an wrote:
I just want to solve them. I know it's difficult for every developer. So if
you come across similar issues, you
don't need to spend too much time trying to solve them on your own.
Yes, I understand very well, but fixing too fast can lead to bugs
elsewh
> The real prejudice is on my side when it takes one week to update from a
> 6 month old nuttx and the resulting image does not even run. Can you
> imagine this burden and frustration and stress? My boss is not happy
> about this and it's not my fault. I know it's an open source project
> without w
Hello,
The real prejudice is on my side when it takes one week to update from a
6 month old nuttx and the resulting image does not even run. Can you
imagine this burden and frustration and stress? My boss is not happy
about this and it's not my fault. I know it's an open source project
withou
> This is not an Apache Project communication channel, so it does not
> exist as far as we are all concerned.
actually we've had extensive discussions on the community PR, but no one
has ever cared about this issue. I would feel highly honored if I could get
some tips from you.
https://github.com/
Hi,
On 05/02/2025 13:03, chao an wrote:
I talked with
Xiaoxiang in WeChat before.
This is not an Apache Project communication channel, so it does not
exist as far as we are all concerned.
These changes MUST be tested in a separate code branch so all platforms
can be tested and validated f
ual developers and projects.
> The
> > new semantics should be named with a new API to minimize the impact.
> >
> > BRs,
> >
> > hujun260 于2025年2月5日周三 19:19写道：
> >
> > > I reverted the relevant changes.
> > >
> > >
> > >
25年2月5日周三 19:19写道：
>
> > I reverted the relevant changes.
> >
> >
> > https://github.com/apache/nuttx/pull/15767
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > At 2025-02-05
2025-02-05 13:06:29, "chao an" wrote:
> >Hi,
> >
> >The behavior of spin_lock needs everyone's advice
> >
> >After PR14578 <https://github.com/apache/nuttx/pull/14578> was merged
> into
> >the NuttX, the behavior of spin_lock() and spin_lock_i
Hello Xiaomi dev team,
If I understand correctly spinlocks are basically a no-op when no SMP is
involved, which is the majority of CPUs supported by NuttX. You shall
not break all platforms.
I urge you all to revert any commit that might have broken something in
this domain, redesign it care
>It isn't an initialization problem, the real cause is some code abusing
>spin lock(lock/unlock in the different thread).
>After holding sched_lock in spinlock_irqsave, the api requires that the
>lock/unlock come from the same thread.
So this brings up a potential problem with spin_lock, right?
>
On Wed, Feb 5, 2025 at 1:06 PM chao an wrote:
> Hi,
>
> The behavior of spin_lock needs everyone's advice
>
> After PR14578 <https://github.com/apache/nuttx/pull/14578> was merged into
> the NuttX, the behavior of spin_lock() and spin_lock_irqsave() added the
> f
Hi,
The behavior of spin_lock needs everyone's advice
After PR14578 <https://github.com/apache/nuttx/pull/14578> was merged into
the NuttX, the behavior of spin_lock() and spin_lock_irqsave() added the
feature of disable the preemption:
https://github.com/apache/nuttx/pull/14578
Th
18 matches
Mail list logo
