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-standard API that is (probably)
supported by every operating system. NuttX *must* continue to support
this as an internal OS API as does every other operating system that I
am aware of:
* Linux has pre-empt disable:
https://www.kernel.org/doc/Documentation/preempt-locking.txt,
https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/preempt.c#L58
* Zephyr has k_sched_lock():
https://docs.zephyrproject.org/3.0.0/reference/kernel/scheduling/index.html
* (I am too lazy to verify others).
Removing it from NuttX would be very, very bad idea. It would damage
the real time behavior of NuttX (because the only alternative is to
disable interrupts). And would make NuttX less capable than its
counterparts.
Let's make sure that never happens.
But...
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 application control of the pre-emption state, and,
in fact, I think it is a security issue that we permit this. Does it
really make since that any application should be able to just stop the
scheduler????
There are many uses of sched_lock() in apps/ now:
$ grep -rl sched_lock apps
apps/examples/calib_udelay/calib_udelay_main.c
apps/examples/i2schar/i2schar_main.c
apps/graphics/nxwidgets/src/cnxtkwindow.cxx
apps/graphics/nxwidgets/src/cwidgetcontrol.cxx
apps/graphics/nxwidgets/src/singletons.cxx
apps/graphics/nxwm/src/cnxterm.cxx
apps/graphics/nxwm/src/ctouchscreen.cxx
apps/graphics/twm4nx/apps/cclock.cxx
apps/graphics/twm4nx/apps/cnxterm.cxx
apps/include/graphics/nxwidgets/cwidgetcontrol.hxx
apps/libapps.a
apps/netutils/netinit/netinit.c
apps/netutils/ntpclient/ntpclient.c
apps/nshlib/nsh_builtin.c
apps/nshlib/nsh_fileapps.c
apps/nshlibapps/nshlib/nsh_script.c
apps/system/critmon/critmon.c
apps/system/stackmonitor/stackmonitor.c
apps/system/zmodem/host/nuttx/config.h
apps/system/zmodem/zm_state.c
apps/testing/ostest/fpu.c
apps/testing/ostest/prioinherit.c
apps/testing/ostest/roundrobin.c
apps/testing/ostest/signest.c
apps/testing/ostest/sporadic.c
It might be possible to re-design some of these to avoid disabling
pre-emption. I am not sure. We would probably lose some of them and
the re-design of the others could be a very complicated job.
OStest, for example, requires sched_lock() to control order of execution
of threads to set up test cases. Without sched_lock(), we could not
test the OS from user space. OStest has historically used internal OS
interface in order to implement semi-white-box testing.
My position is:
* We have to keep sched_lock() as an OS internal interface and retain
its current behavior.
* Re-naming the interface, documenting the interface, doing whatever
we can to assure proper usage is fine.
* I have mixed feelings about removing user access to sched_lock(). I
think it is the correct thing to do, but I don't know if I would
like the consequences of that decision.
NOTE: sched_lock() was documented in the past, but that documentation
was removed from the repository and from general access for some reason:
https://cwiki.apache.org/confluence/display/NUTTX/User+Guide#schedlock
