Re: New names of repositories

+1 , nuttx/nuttx-apps, I perfer nuttx, the "X" in NuttX means more possibilities, "X" can be RTOS, or something else archer, BRs, Gustavo Henrique Nihei 于2022年11月18日周五 23:32写道： > I vote for nuttx and nuttx-apps. > I agree with the above reasons for using dashes (-) instead of underscore. > > O

The behavior of spin_lock needs everyone's advice

Hi, The behavior of spin_lock needs everyone's advice After PR14578 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 The spin lock b

Re: The behavior of spin_lock needs everyone's advice

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

Re: The behavior of spin_lock needs everyone's advice

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. > > > https://github.com/apache/nuttx/pull/15767 > > > > > > > > > > > > > > > At

Re: The behavior of spin_lock needs everyone's advice

Sebastien Lorquet 于2025年2月5日周三 22:01写道： > 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. > > >

Re: The behavior of spin_lock needs everyone's advice

> > Pre-staging your changes for some time before contributing would be a > great step in getting everything better. It would allow more time for > reaction. > > > On 05/02/2025 15:11, chao an wrote: > >> This is not an Apache Project communication channel, so it does not

Re: The behavior of spin_lock needs everyone's advice

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. > > BRs, > ligd > > chao an 于2025年2月5日周三 19:34写道： > > > I do not agree with the reve

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

Hi, Greg， Glad to hear your voice. In the current crc16 implementation, we have provided 3 variants. The default crc16 semantics is CRC-16/XMODEM: CRC-16/XMODEM: crc16 crc16part https://github.com/apache/nuttx/blob/master/libs/libc/misc/lib_crc16.c CRC-16/CCITT-TRUE: crc16ccitt crc16c

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

I still insist on my opinion that compatibility with popular operating systems is the best choice The issues we are discussing now are limited to the premise of not breaking existing products, but your decision has broken‌‌ all future programs that want to compatible NuttX but these programs have

Re: Vote for rename modlib to libelf

RIBUTING.md, > this change doesn't seem even eligible for voting because > it is not "absolutely necessary and unavoidable". > > i personally like the change itself and prefer loosening the rules in > CONTRIBUTING.md though. > > > On Mon, Apr 7, 2025 at 6:13 PM ch

Re: Vote for rename modlib to libelf

avoidable" constraint. In addition, I don't think PMC has any privileges. Anyone can vote on the mailing list, and we also need the opinions of experts like you. BRs, Takashi Yamamoto 于2025年4月10日周四 10:37写道： > > > On Thu, Apr 10, 2025 at 10:44 AM chao an wrote: > >> Yamamo

Re: Vote for rename modlib to libelf

@yamamoto Thanks for your comments! BRs, Takashi Yamamoto 于2025年4月10日周四 11:37写道： > > > On Thu, Apr 10, 2025 at 11:55 AM chao an wrote: > >> This change has no functional impact, so it does not meet the "absolutely >> necessary and unavoidable" constrai

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

://www.apache.org/foundation/voting.html#LazyConsensus> > <https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 votes > are required for a code-modification proposal to pass." > > > > > Sebastien > > > On 09/04/2025 10:20, chao an wro

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

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

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

> > I am against changing the default implementation of the legacy function > silently. > > I would be less mad if you REMOVED the old function rather than silently > changing its behaviour. (that would still be bad, however) > > Sebastien > > > On 09/04/2025 05:12, ch

Re: Vote for rename modlib to libelf

nge, > actual tests are being made and additional required fixes have been found. > > Also communication efforts have been made beforehand. > > I am grateful for this. > > > Best regards, > > Sebastien > > > On 07/04/2025 11:13, chao an wrote: > > Hi com

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

t MUST NOT PROCEED. > > I still think you can introduce additional routines to compute other CRC > variations, but the default crc MUST DEFINITELY NOT CHANGE. > > Use the new routines in a wrapper in your code, but DO NOT CHANGE the > default CRC algorithm > > This is an ABSOLUTELY CR

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

I want to reach a consensus with everyone We have spent too much time explaining similar issues to different developers. we can see that @Alan has wanted to promote this for a long time. As Lwazi said, the discussion in the community is for code and future directions, not for politics. If the expe

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

x%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code [image: image.png] BRs, Tomek CEDRO 于2025年4月9日周三 10:52写道： > On Wed, Apr 9, 2025 at 3:45 AM chao an wrote: > > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube > wrote: &

Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

Hi Community, I plan to switch the default CRC16 algorithm directory of NuttX from CRC-16/XMODEM to CRC-16/IBM: https://github.com/apache/nuttx/pull/16147 CRC-16/XMODEM as the default implementation has significant limitations, especially when communicating with popular operating systems and it c

Vote for rename modlib to libelf

Hi community, Some green hand and individual developer who are not familiar with nuttx may be confused by the naming of modlib, in currect implement, modlib as an elf loader and parser, does not provide any features other than elf. In this pull request, I plan to rename modlib to elf, and adjust

Re: Vote for using system dd instead of nsh dd, avoid duplicate code

+1 The duplication of the same features in the system is a nuisance to developers, who do not understand which version to use or which version has more advantages. In addition, removing redundancy also helps optimize the usage of flash/ram. BRs, Tomek CEDRO 于2025年4月14日周一 22:18写道： > Thanks Xiang

Re: Vote for rename modlib to libelf

Hi community, I believe we have reached a consensus in this mail thread. Please allow me to end the current vote. The final result is: +1: 9 +0: 3 -1: 0 Thanks everyone for your valuable comments. cc @lupyuen BRs, chao an 于2025年4月7日周一 17:13写道： > Hi community, > > Some green

HaloOS: Implementation of AutoSAR OS based on the NuttX kernel

Here is an interesting OS, an implementation of AutosarOS based on the Nuttx kernel, which seems to follow the OSEK OS standard: HaloOS: https://gitee.com/haloos NuttX Kernel: https://gitee.com/haloos/vcos_kernel_nuttx AutosarOS(OSEK) based on NuttX Kernel: https://gitee.com/haloos/vcos_compone

Re: Vote for rename modlib to libelf

ormation was reassuring, I am not opposing it anymore. > > Care is being taken about this issue, that is the most important of all. > > Sebastien > > > On 07/04/2025 15:35, chao an wrote: > > @ Sebastien Lorquet > > > - breaks several build you had to fix incrementall