mirror of
https://github.com/apache/nuttx.git
synced 2026-10-11 08:10:21 +00:00
f6ecf80ebb
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
52 lines
2.3 KiB
Markdown
52 lines
2.3 KiB
Markdown
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.
|
|
|