Thanks. I remember this now. We talked about this back in 2019!GregSent from
my Galaxy
Original message From: Xiang Xiao
Date: 4/23/23 10:09 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: Re:
sched_lock() should be completely removed On Sun, Apr 23, 2023 at 10:42 PM
Greg
On Sun, Apr 23, 2023 at 10:42 PM Gregory Nutt wrote:
>
> > Let's focus on the first two item:
> >
> > 1. Add sched_lock()'s ability to the enter_critical_section()
>
> Some will need to explain what this means. What is this?
If someone wakes up a high priority thread inside the critical se
This is build from the repo and automatically published.
This particular file source is located here:
https://github.com/apache/nuttx/blob/master/Documentation/reference/user/03_task_control.rst
From the main documentation page you would find this under the API
Reference section and then U
On 4/23/2023 10:16 AM, Brennan Ashton wrote:
On Sun, Apr 23, 2023, 3:57 PM Gregory Nutt wrote:
Possibly stupid idea: Maybe OStest needs
That point is that there was a lot of valuable documentation that has
been thrown in the shitcan and replaced with superficial how-to
documentation. There i
On Sun, Apr 23, 2023, 3:57 PM Gregory Nutt wrote:
>
> > Possibly stupid idea: Maybe OStest needs
> That point is that there was a lot of valuable documentation that has
> been thrown in the shitcan and replaced with superficial how-to
> documentation. There is no longer technical documentation i
Possibly stupid idea: Maybe OStest needs to become part of the OS and
not part of apps?
That is possible but leads to some issues some of which are only
cosmetic and some which are semantic.
* If we did that, it would not be an OS test. It would be an OS self
test of some kin.
* You c
Let's focus on the first two item:
1. Add sched_lock()'s ability to the enter_critical_section()
Some will need to explain what this means. What is this? Why is it
needed? There is not sufficient information in this statement to
understand it.
On Sun, Apr 23, 2023 at 10:22 AM Gregory Nutt wrote:
> These are internal OS interfaces. In NuttX, sched_lock() is exported as
> a standard application interface. That, I think is wrong. An
> application should not require such an interface, there is no precedent
> in any standard for applicati
hey there Yun, i am also strongly against removing working code that had
been here for a long time has been carefully designed gives granular
control etc.
Good words to like by:
* If it ain't broke don't fix it.
* Evolution , not revolution.
In the case of sched_lock(), it is a non-standar
Here is an example we found recently:
https://github.com/apache/nuttx/pull/9002/files
it's always wrong to use shced_lock as lock to protect the shared resource
like this.
Here is an issue which list all fixed done before:
https://github.com/apache/nuttx/issues/3600
Since it's very hard to reproduc
Hello, just a recommendation.
If something is prone to missuse by the users, don't remove it.
Rather:
* Document clearly it's quirks.
* Provide checks and assertions catching the missuse.
On Sun, Apr 23, 2023, 14:49 Sebastien Lorquet wrote:
> Hello,
>
> I have a similar feeling about this.
>
Hello,
I have a similar feeling about this.
Remember, if it isn't broken, dont fix it.
Sebastien
On 4/23/23 13:32, Tomek CEDRO wrote:
hey there Yun, i am also strongly against removing working code that had
been here for a long time has been carefully designed gives granular
control etc.
un
hey there Yun, i am also strongly against removing working code that had
been here for a long time has been carefully designed gives granular
control etc.
understanding of the code and possible misuse is up to developer.
maybe the problem needs better explanation and discussion which is always
go
Gregory Nutt 于2023年4月23日周日 04:24写道：
> I am not sure what this mean. But if you mean calling
> enter_critical_secion() in sched_lock(), then it is a very bad idea You
> should not do that. enter_critical_section() disables interrupts on all
> CPUs and this must never happen when disabling preem
14 matches
Mail list logo
