Re: NuttX Code Quality Improvement 2025Q1

Hi Tomek, I think most of the points make sense, just few notes to some of them. > * Number of required code reviews should be increased from 2 to 4. > This will ensure cross-checks and filter out faulty changes. Perhaps I would limit this to larger commits only (and all affecting Build / Kernel

Re: NuttX Code Quality Improvement 2025Q1

On Thu, Feb 6, 2025 at 4:45 AM Tomek CEDRO wrote: > We have long discussions over the last months NuttX code quality and > self-compatibility degradation. I think open discussion in this area > as for 2025Q1 can be constructive. Please join the discussion :-) > (..) There are separate mailing lis

NuttX Code Quality Improvement 2025Q1

Hello world :-) We have long discussions over the last months NuttX code quality and self-compatibility degradation. I think open discussion in this area as for 2025Q1 can be constructive. Please join the discussion :-) After we have a good understanding and agreement on selected points we should

Re: The behavior of spin_lock needs everyone's advice

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

Re: [DRUNX] Distributed Runtime and bUild for NuttX

On Wed, Feb 5, 2025 at 8:25 AM raiden00pl wrote: > But first we should determine what things we want to test, not what boards. > Knowing what things we want to test, we can design test cases and possibly > use what is already available. This will be part of the drunx architecture, but I have crea

Re: [DRUNX] Distributed Runtime and bUild for NuttX

On Wed, Feb 5, 2025 at 3:12 PM Sebastien Lorquet wrote: > This project is not even started yet :-) Ekhem, its here already for some months in that form or another (see Lup's CI and Dashboard, see my wall), not corporate style, not wearing suits and expensive watches, not yet as we want, not yet a

Re: [DRUNX] Distributed Runtime and bUild for NuttX

On Wed, Feb 5, 2025 at 8:25 AM raiden00pl wrote: > As mentioned earlier, testing all boards is pointless, especially since the > project > has very limited resources. Choosing a few boards that will allow us to > test as many > things as possible is the most optimal approach. Quite the opposite :

Re: The behavior of spin_lock needs everyone's advice

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

Re: The behavior of spin_lock needs everyone's advice

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

Re: The behavior of spin_lock needs everyone's advice

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

Re: The behavior of spin_lock needs everyone's advice

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:

Re: GSoC 2025

On Tue, Feb 4, 2025 at 11:06 PM Michal Lenc wrote: > there is still a possible work to do though. We could try to design an > alternative algorithm that would not need three partitions. There are > advantages of the current design (fast update even for big images, low > flash wear, you always have

Re: The behavior of spin_lock needs everyone's advice

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

Re: The behavior of spin_lock needs everyone's advice

> 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

Re: The behavior of spin_lock needs everyone's advice

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

Re: [DRUNX] Distributed Runtime and bUild for NuttX

I would say testing as much as possible is always a benefit. I have worked for more than 15 years as an embedded specialist managing mission critical code, and every bug we found later in the project was in a test gap. As my boss usually say, "If it's not tested, it doesnt work" and this has

Re: The behavior of spin_lock needs everyone's advice

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

Re: The behavior of spin_lock needs everyone's advice

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

Re: [DRUNX] Distributed Runtime and bUild for NuttX

or starting to implement a monster that only prevents anyone from changing. "No change anymore" can be implemented easier, just stop working and go on vacation, haha. But no joke, that's also a way to send a project to death. -- Hard- and Softwaredevelopment Consultant Geschäftsführung: Simon Fil

Re: [DRUNX] Distributed Runtime and bUild for NuttX

Dear all, each arch, driver and app tested once would be enough I think. A matrix can help to identify test-gaps. Double testing is nice and triple testing is not of benefit any more. The goal should be to have fast access to results with transparency. I fear starting to maintain a useless monste

Re: [DRUNX] Distributed Runtime and bUild for NuttX

I think we should test the most complete/complex boards from each arch. It will cover most of the issues that could after other boards. BR, Alan On Wed, Feb 5, 2025 at 4:23 AM raiden00pl wrote: > As mentioned earlier, testing all boards is pointless, especially since the > project > has very l

Re: The behavior of spin_lock needs everyone's advice

> Then can we have a method that takes both ? > Based on option1, we add a check if someone called sem_post()/syslog()... > then system ASSERT. Alert the people who should change their usage. > And also the performance will be considered. Hi, Guiding I fully agree with your opinion. This is also

Re: The behavior of spin_lock needs everyone's advice

Hi Chao, For these two options: *Option 1:* spin_lock: spin lock spin_lock_nopreempt:spin_lock + sched_lock spin_lock_irqsave: spin lock + irqsave spin_lock_irqsave_nopreempt: spin_lock + irq save + sched_lock *Option 2:*

Re: The behavior of spin_lock needs everyone's advice

I do not agree with the revert related changes. Local locks are very helpful for system real-time performance. I just have some suggestions on API semantics. Changes of kernel API semantics need to be carefully considered, especially if these functions will be used by individual developers and pro

Re:The behavior of spin_lock needs everyone's advice

I reverted the relevant changes. https://github.com/apache/nuttx/pull/15767 At 2025-02-05 13:06:29, "chao an" wrote: >Hi, > >The behavior of spin_lock needs everyone's advice > >After PR14578 was merged into >the NuttX, the behavior of s

Re: The behavior of spin_lock needs everyone's advice

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

Re: HW Testing Platform Suggestion

Hello, I respectfully suggest to reduce the required hardware development to the absolute minimum otherwise it will never move forward in a satisfactory manner. Many devboards can be flashed over usb and provide an UART. IMHO it represents a sufficiently complex first step towards hardware