mirror of
https://github.com/apache/nuttx.git
synced 2026-10-08 06:45:19 +00:00
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
2.3 KiB
2.3 KiB
NuttX-5.10
This is the 57th release of NuttX. This release includes a combination of some new features as well as several bugfixes. New features include:
- TI/Luminary Stellaris LM3S9B96: Header file changes contributed by Tiago Maluta.
- TI/Luminary Stellaris LM3S8962: Header file changes and support for the Stellaris LM3S8962 Ethernet+CAN Evaluation Board contributed by Larry Arnold.
- On-Demand Paging Support: The basic logic for the On-Demand Paging feature is complete, implemented for the NXP LPC3131, and partially tested. See https://nuttx.apache.org/docs/latest/components/paging.html. Some additional test infrastructure will be needed in order to complete the verification. See configs/ea3131/README.txt for details.
- Two Pass Build Support: The make system now supports a two pass build where a relocatable, partially linked object is created on the first pass and that object is linked with the NuttX libraries to produce the final executable on the second pass. This two pass build is currently only used to support the On-Demand paging feature: The first pass link forces critical logic into the locked text region; the second pass builds the NuttX executable more-or-less as normal.
- CONFIG_APP_DIR: Generalized the way in which applications are built and linked with NuttX. The new configuration CONFIG_APP_DIR replaces CONFIG_EXAMPLE. CONFIG_EXAMPLE used to identify the sub-directory within the NuttX examples/ directory that held the example application to be built. That made it awkward to configure to build an application that resides outside of the NuttX examples/ directory. CONFIG_APP_DIR is more general; it can be used to refer to any directory containing the application to be built.
For people who have their own configurations and/or Makefiles, you will need to make a couple of changes:
- Replace all occurrences of CONFIG_EXAMPLE=foobar with CONFIG_APP_DIR=examples/foobar in all of the configuration files.
- Replace any occurrences of examples/$(CONFIG_EXAMPLE) with $(CONFIG_APP_DIR)
- Replace any occurrences of lib$(CONFIG_EXAMPLE)$(LIBEXT) with libapp$(LIBEXT) in your Makefiles.
- Check any other occurrences of CONFIG_EXAMPLE.
- Several bugfixes are included as well as code changes to eliminate some warnings. See the ChangeLog for details.