This change has no functional impact, so it does not meet the "absolutely
necessary and unavoidable" constraint.
But this commit will affect everyone's understanding of the kernel's key
features, which is a good thing in further. I think it meets the "necessary
and unavoidable" constraint.
In addit
On Thu, Apr 10, 2025 at 10:44 AM chao an wrote:
> Yamamoto san, there may be some objective factors here, but we may already
> be on the way to voting. could you please vote again based on the changes
> from the "code" perspective?
>
i've read CONTRIBUTING.md 1.12 and 1.13 a few times.
but i don
Hi yf,
thanks for confirming
May I count your vote +1?
Thanks
Alin
On Thu, 10 Apr 2025, 03:37 Yanfeng Liu, wrote:
> Lup,
>
> Thanks a lot. I will retry later.
>
> Alin,
>
> I am okay with this release, the issue I encountered here may be my
> environment
> specific.
>
> Regards,
> yf
>
>
> O
@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" constraint.
>> But this commit will affect everyon
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" constraint.
> But this commit will affect everyone's understanding of the kernel's key
> features, which is a good thing in further. I think it
-1 from me also, but please read further:
I would vote +1 if there is a Kconfig to select crc16 type, and
current (backwards-compatible) type is default. This way, existing
applications will not break suddenly, but developers who need
different CRC can choose it from Kconfig.
In addition, I like
Yamamoto san, there may be some objective factors here, but we may already
be on the way to voting. could you please vote again based on the changes
from the "code" perspective?
BRs,
Takashi Yamamoto 于2025年4月9日周三 06:56写道：
> -1
>
> reading the recently added text in CONTRIBUTING.md,
> this chang
Lup,
Thanks a lot. I will retry later.
Alin,
I am okay with this release, the issue I encountered here may be my environment
specific.
Regards,
yf
On Wed, 2025-04-09 at 17:08 +0800, Lee, Lup Yuen wrote:
> << I can boot into NSH but when running python, it crashed. >>
>
> Hi YF: QEMU 8.2.2 +
Agree! This will end this discussion! And it will make it clear what
algorithm was used.
BR,
Alan
On Wed, Apr 9, 2025 at 9:07 AM Nathan Hartman
wrote:
> I think the real problem here is that the function is called crc16() with
> no details about which CRC polynomial is used. Maybe it's better
Look for yourself. For the past few years all my NuttX commits are bug
fixes.
You are talking to the wrong guy.
On Wed, 9 Apr 2025 at 12:39, Sebastien Lorquet wrote:
> There was no diatribe this time. I had the same single argument the
> whole time: for long term self compatibility, we can not c
Too late. If I am reading the PR correctly, he has changed the subject and
we are back to the original default.
uint16_t crc16(FAR const uint8_t *src, size_t len)
{
return crc16xmodempart(src, len, 0);
}
He fought for a couple of days before giving up. I don't blame him. This
suggestion, which
There was no diatribe this time. I had the same single argument the
whole time: for long term self compatibility, we can not change the
behaviour of existing critical code. That's what matter.
We just added the complete deletion idea later.
The addition of new, well specified CRC routines is v
Yes.
This function was not carefully specified, we just have to acknowledge
that. it was a past mistake, but now it's here, and we need to support
it in a stable way.
About that function, the only thing to do is to properly document what
it actually does, and keep it that way. There is no re
This proposal looks reasonable to me. Also a few people disagreed with my
earlier Kconfig idea and this proposal avoids introducing such a Kconfig,
so I think it's an improvement. I'm +1 to this idea.
On Wed, Apr 9, 2025 at 9:08 AM Sebastien Lorquet
wrote:
> Yes.
>
> This function was not carefu
On Wed, 9 Apr 2025 at 03:43, Sebastien Lorquet wrote:
> >
> >> I Maintain, DO NOT CHANGE THE DEFAULT CRC ROUTINE.
> >>
> > No. The open source project provides the ability for proprietary forks to
> > override the master branch default with the company default. Your
> approach
> > stalls the deve
Seriously, I have no interest in crc16 at all, and I don't think your 15
years of experience in cryptography deserves my respect.
These are all old technologies. I just want to help people who have
problems in Nuttx.
I also hope that every time someone asks about the implementation of crc16,
you ca
I think the real problem here is that the function is called crc16() with
no details about which CRC polynomial is used. Maybe it's better not to
have this function at all and to have *only* functions with names like
crc16ibm() or crc16ccitt(). Then it is much more clear what CRC is being
called in
Lup,
Thanks for the information, I can build with xpack toolchain 13.2 here now.
However, when running the build following the guide in Documentations/ folder. I
can boot into NSH but when running python, it crashed.
Can your build run well there?
Regards.
yf
On Wed, 2025-04-09 at 07:51 +000
Why are you so unwilling to change your opinion?
You are ready to break nuttx just for your comfort, in whatever way it
may take to advance your own agenda. That is very political.
I dont like that.
We need a consensus, and a majority of this thread is against the change
you want to make. So
<< I can boot into NSH but when running python, it crashed. >>
Hi YF: QEMU 8.2.2 + NSH + Python works OK for me (I built `rv-virt:python`
with Docker + Ubuntu). Here's the QEMU Log:
https://gist.github.com/lupyuen/31db63ccfaf0e07c45ba0059814e0fd7
NuttShell (NSH) NuttX-12.9.0
nsh> uname -a
NuttX
I like your second option, so could we remove the implementation of both
crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?
BRs,
Sebastien Lorquet 于2025年4月9日周三 16:00写道：
> Hello,
>
> once again, the number of usage is unimportant and irrelevant.
>
> The ONLY thing that matters
Hello,
once again, the number of usage is unimportant and irrelevant.
The ONLY thing that matters is that when I call function POOP, it always
does POOP. Not something else.
Because users you are unaware of expect this function to do POOP and
they may not be able to change their code.
If y
Hi Liu,
thanks for your feedback
Can you link the missing patches?
Thanks
Alin
Från: Yanfeng Liu
Skickat: den 9 april 2025 09:42
Till: dev@nuttx.apache.org
Ämne: Re: [VOTE] Apache NuttX 12.9.0 RC0 release
Hi, -1 here. Checked mainly with rv-virt on Ubuntu 22.
I Maintain, DO NOT CHANGE THE DEFAULT CRC ROUTINE.
No. The open source project provides the ability for proprietary forks to
override the master branch default with the company default. Your approach
stalls the development process. A trivial change like this should not take
a week to commit.
Hi,
-1 here.
Checked mainly with rv-virt on Ubuntu 22.04 with riscv64-unknown-elf-gcc
toolchain 10.2.0 mainly.
Passed configs: nsh, knsh, nsbi, flats
Minor issue:
- rv-virt:python (failed to build with both 10.2 and 14.2)
Regards,
yf
On Tue, 2025-04-08 at 07:21 +0200, Alin Jerpelea wrote:
25 matches
Mail list logo
