nuttx/Documentation/os/notifier.rst
Vinicius May f6ecf80ebb Documentation: brand new layout for NuttX documentation.
The documentation grew one page at a time, so the tree follows the
history of who wrote what and not the shape of NuttX. Scheduling is
spread over three places, a driver page can sit above the subsystem
that owns it, and the front page lists everything at the same level.
That is a lot to face when all you want to know is where the scheduler
lives.

This change files every page under the code it describes. It is a move,
not a rewrite: outside the ten pages named below, every page keeps the
text that is already in master, and no page's text is deleted.

What it does:

* Groups the table of contents into nine chapters.
* Moves the OS subsystems under os/: scheduling, memory, drivers,
  filesystem, networking, IPC, interrupts, libs, time.
* Renames the platform pages to the names the source tree uses, and
  derives their tags from the tree instead of by hand.
* Splits guides/ by subject.
* Adds Documentation/redirects.py, with a rule for every page that left
  its old path, so old URLs keep working. The redirect page also carries
  a link's #anchor across to the new page.

Ten pages have text that is new or rewritten. Nine of them are the
landing page of a chapter, which has to exist for the new structure:

    index                  the front page
    os/index               OS Design
    os/scheduling/index    Scheduling
    os/interrupts/index    Interrupts
    os/ipc/index           IPC
    os/time/index          Time and timers
    about/index            About
    developing/index       Developing NuttX
    ReleaseNotes/index     Release notes

The tenth is os/libs/libbuiltin, the only page here with technical
content: libs/libbuiltin/ had no page at all. Five SVG diagrams come
with these pages, hand-written XML with no editor metadata.

Nothing outside Documentation/ is touched.

How it was checked:

* Sphinx builds with -W: no warnings, and no document left outside a
  toctree.
* A script, offered in the PR, proves the narrow claim this rests on.
  For every page outside the ten named above it erases what a move
  touches -- link target, path, tag line, toctree block, table border --
  from the whole old text and the whole new text, and requires the two
  to be byte for byte identical. It also requires every sentence of a
  deleted page to turn up somewhere, and every page that left its old
  path to have a redirect, from a URL that existed, to where its content
  went. It exits non-zero and names the page if any of that is not true,
  and it tests added pages too, so forgetting to declare one cannot make
  it pass.
* An independent audit checked 133 factual claims on these ten pages
  against the tree, one shell command per claim: 130 confirmed, 1
  refuted and fixed here, 2 not checkable.
* tools/checkpatch.sh is clean over the range.

The diff is large because moving a page changes every link that points
to it. Most of it is pure renames, and board pages that gained one tag
line.

Assisted-by: Claude:claude-opus-5
2026-10-08 01:40:54 +08:00

97 lines
2.9 KiB
ReStructuredText

.. _notifier_chain:
==============
Notifier Chain
==============
NuttX provides a callback list mechanism called *Notifier Chain*.
Notifier chain is essentially a list of callbacks used at certain times,
such as system asserting, powering off and restarting.
**Notifier chain** is very much like the Linux notifier chains, except
for some implementation differences.
Classes of Notifier Chain
=========================
There are currently two different classes of notifier.
Atomic notifier chains
----------------------
Atomic notifier chains: Chain callbacks run in interrupt/atomic context.
In Nuttx, callouts are allowed to block(In Linux, callouts in atomic
notifier chain are not allowed to block). One example of an Atomic notifier
chain is turning off FPU when asserting.
Blocking notifier chains
------------------------
Blocking notifier chains: Chain callbacks run in process context.
Callouts are allowed to block. One example of a blocking notifier chain
is when an orderly powering off is needed.
Common Notifier Chain Interfaces
================================
Notifier Block Types
--------------------
- ``struct notifier_block``. Defines one notifier callback entry.
Notifier Chain Interfaces
-------------------------
.. c:function:: void panic_notifier_chain_register(FAR struct notifier_block *nb)
Add notifier to the panic notifier chain.
The panic notifier chain is an atomic notifier chain. It will be called
when asserting.
:param nb: New entry in notifier chain.
.. c:function:: void panic_notifier_chain_unregister(FAR struct notifier_block *nb)
Remove notifier from the panic notifier chain.
The panic notifier chain is an atomic notifier chain. It will be called
when asserting.
:param nh: Entry to remove from notifier chain.
.. c:function:: void panic_notifier_call_chain(unsigned long action, FAR void *data)
Call functions in the panic notifier chain.
The panic notifier chain is an atomic notifier chain. It will be called
when asserting.
:param action: Value passed unmodified to notifier function.
:param data: Pointer passed unmodified to notifier function.
.. c:function:: void register_reboot_notifier(FAR struct notifier_block *nb)
Add notifier to the reboot notifier chain.
The reboot notifier chain is an atomic notifier chain.
:param nb: New entry in notifier chain.
.. c:function:: void unregister_reboot_notifier(FAR struct notifier_block *nb)
Remove notifier from the reboot notifier chain.
The reboot notifier chain is an atomic notifier chain.
:param nh: Entry to remove from notifier chain.
.. c:function:: void reboot_notifier_call_chain(unsigned long action, FAR void *data)
Call functions in the reboot notifier chain.
The reboot notifier chain is an atomic notifier chain.
:param action: Value passed unmodified to notifier function.
:param data: Pointer passed unmodified to notifier function.