michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: Fix links to Zephyr include directory on Github

Browse source 
At some recent point, directory <zephyr-root>/include was moved to
<zephyr-root>/include/zephyr. However, links from documentation to
Zephyr source on Github were not updated. Update them now.

Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
This commit is contained in:
Aleksandar Markovic 2022-04-16 22:10:28 +02:00 • committed by Anas Nashif
commit 7af3b8cbb3
24 changed files with 39 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/build/cmake/index.rst vendored
View file

@ -92,7 +92,7 @@ Devicetree
preprocessor macros. preprocessor macros.
Source code should access preprocessor macros generated from devicetree by Source code should access preprocessor macros generated from devicetree by
including the :zephyr_file:`devicetree.h <include/devicetree.h>` header, including the :zephyr_file:`devicetree.h <include/zephyr/devicetree.h>` header,
which includes :file:`devicetree_unfixed.h`. which includes :file:`devicetree_unfixed.h`.
:file:`gen_defines.py` also writes the final devicetree to :file:`gen_defines.py` also writes the final devicetree to

2
doc/connectivity/networking/api/dns_resolve.rst
View file

@ -30,7 +30,7 @@ about LLMNR.
For more information about DNS configuration variables, see: For more information about DNS configuration variables, see:
:zephyr_file:`subsys/net/lib/dns/Kconfig`. The DNS resolver API can be found at :zephyr_file:`subsys/net/lib/dns/Kconfig`. The DNS resolver API can be found at
:zephyr_file:`include/net/dns_resolve.h`. :zephyr_file:`include/zephyr/net/dns_resolve.h`.
Sample usage Sample usage
************ ************

2
doc/connectivity/networking/api/net_buf.rst
View file

@ -13,7 +13,7 @@ Overview
Network buffers are a core concept of how the networking stack Network buffers are a core concept of how the networking stack
(as well as the Bluetooth stack) pass data around. The API for them is (as well as the Bluetooth stack) pass data around. The API for them is
defined in :zephyr_file:`include/net/buf.h`:. defined in :zephyr_file:`include/zephyr/net/buf.h`:.
Creating buffers Creating buffers
**************** ****************

6
doc/connectivity/networking/api/net_l2.rst
View file

@ -13,11 +13,11 @@ Overview
The L2 stack is designed to hide the whole networking link-layer part The L2 stack is designed to hide the whole networking link-layer part
and the related device drivers from the upper network stack. This is made and the related device drivers from the upper network stack. This is made
through a :c:struct:`net_if` declared in through a :c:struct:`net_if` declared in
:zephyr_file:`include/net/net_if.h`. :zephyr_file:`include/zephyr/net/net_if.h`.
The upper layers are unaware of implementation details beyond the net_if The upper layers are unaware of implementation details beyond the net_if
object and the generic API provided by the L2 layer in object and the generic API provided by the L2 layer in
:zephyr_file:`include/net/net_l2.h` as :c:struct:`net_l2`. :zephyr_file:`include/zephyr/net/net_l2.h` as :c:struct:`net_l2`.
Only the L2 layer can talk to the device driver, linked to the net_if Only the L2 layer can talk to the device driver, linked to the net_if
object. The L2 layer dictates the API provided by the device driver, object. The L2 layer dictates the API provided by the device driver,
@ -119,7 +119,7 @@ here as well. There are two specific differences however:
- It requires a dedicated device driver API: :c:struct:`ieee802154_radio_api`, - It requires a dedicated device driver API: :c:struct:`ieee802154_radio_api`,
which overloads :c:struct:`net_if_api`. This is because 802.15.4 L2 needs more from the device which overloads :c:struct:`net_if_api`. This is because 802.15.4 L2 needs more from the device
driver than just ``send()`` and ``recv()`` functions. This dedicated API is driver than just ``send()`` and ``recv()`` functions. This dedicated API is
declared in :zephyr_file:`include/net/ieee802154_radio.h`. Each and every declared in :zephyr_file:`include/zephyr/net/ieee802154_radio.h`. Each and every
IEEE 802.15.4 device driver must provide a valid pointer on such IEEE 802.15.4 device driver must provide a valid pointer on such
relevantly filled-in API structure. relevantly filled-in API structure.

10
doc/connectivity/networking/api/net_mgmt.rst
View file

@ -119,7 +119,7 @@ An example follows.
net_mgmt_add_event_callback(&ipv4_callback); net_mgmt_add_event_callback(&ipv4_callback);
} }
See :zephyr_file:`include/net/net_event.h` for available generic core events that See :zephyr_file:`include/zephyr/net/net_event.h` for available generic core events that
can be listened to. can be listened to.
@ -133,9 +133,9 @@ associated mgmt_request code.
Management request code are defined in relevant places depending on Management request code are defined in relevant places depending on
the targeted layer or eventually, if l2 is the layer, on the the targeted layer or eventually, if l2 is the layer, on the
technology as well. For instance, all IP layer management request code technology as well. For instance, all IP layer management request code
will be found in the :zephyr_file:`include/net/net_event.h` header file. But in case will be found in the :zephyr_file:`include/zephyr/net/net_event.h` header file. But in case
of an L2 technology, let's say Ethernet, these would be found in of an L2 technology, let's say Ethernet, these would be found in
:zephyr_file:`include/net/ethernet.h` :zephyr_file:`include/zephyr/net/ethernet.h`
You define your handler modeled with this signature: You define your handler modeled with this signature:
@ -162,9 +162,9 @@ Signaling a network event
You can signal a specific network event using the :c:func:`net_mgmt_event_notify` You can signal a specific network event using the :c:func:`net_mgmt_event_notify`
function and provide the network event code. See function and provide the network event code. See
:zephyr_file:`include/net/net_mgmt.h` for details. As for the management request :zephyr_file:`include/zephyr/net/net_mgmt.h` for details. As for the management request
code, event code can be also found on specific L2 technology mgmt headers, code, event code can be also found on specific L2 technology mgmt headers,
for example :zephyr_file:`include/net/ieee802154_mgmt.h` would be the right place if for example :zephyr_file:`include/zephyr/net/ieee802154_mgmt.h` would be the right place if
802.15.4 L2 is the technology one wants to listen to events. 802.15.4 L2 is the technology one wants to listen to events.
API Reference API Reference

2
doc/connectivity/networking/api/net_pkt.rst
View file

@ -17,7 +17,7 @@ metadata for the core to hold important information. Such an object is
called net_pkt in this document. called net_pkt in this document.
The data structure and the whole API around it are defined in The data structure and the whole API around it are defined in
:zephyr_file:`include/net/net_pkt.h`. :zephyr_file:`include/zephyr/net/net_pkt.h`.
Architectural notes Architectural notes
=================== ===================

2
doc/connectivity/networking/api/net_pkt_filter.rst
View file

@ -45,7 +45,7 @@ can be embedded into a larger structure when a specific condition requires
extra test data. It is up to the test function for such conditions to extra test data. It is up to the test function for such conditions to
retrieve the outer structure from the provided ``npf_test`` structure pointer. retrieve the outer structure from the provided ``npf_test`` structure pointer.
Convenience macros are provided in :zephyr_file:`include/net/net_pkt_filter.h` Convenience macros are provided in :zephyr_file:`include/zephyr/net/net_pkt_filter.h`
to statically define condition instances for various conditions, and to statically define condition instances for various conditions, and
:c:macro:`NPF_RULE()` to create a rule instance to tie them. :c:macro:`NPF_RULE()` to create a rule instance to tie them.

4
doc/connectivity/networking/networking-api-usage.rst
View file

@ -4,7 +4,7 @@ Network Connectivity API
######################## ########################
Applications should use the BSD socket API defined in Applications should use the BSD socket API defined in
:zephyr_file:`include/net/socket.h` to create a connection, send or receive data, :zephyr_file:`include/zephyr/net/socket.h` to create a connection, send or receive data,
and close a connection. The same API can be used when working with UDP or and close a connection. The same API can be used when working with UDP or
TCP data. See :ref:`BSD socket API <bsd_sockets_interface>` for more details. TCP data. See :ref:`BSD socket API <bsd_sockets_interface>` for more details.
@ -12,5 +12,5 @@ See :ref:`sockets-echo-server-sample` and :ref:`sockets-echo-client-sample`
applications how to create a simple server or client BSD socket based applications how to create a simple server or client BSD socket based
application. application.
The legacy connectivity API in :zephyr_file:`include/net/net_context.h` should not be The legacy connectivity API in :zephyr_file:`include/zephyr/net/net_context.h` should not be
used by applications. used by applications.

2
doc/hardware/arch/arm_cortex_m.rst
View file

@ -477,7 +477,7 @@ For example, to define a new non-cacheable memory region in devicetree:
This will automatically create a new MPU entry in This will automatically create a new MPU entry in
:zephyr_file:`soc/arm/common/arm_mpu_regions.c` with the correct name, base, :zephyr_file:`soc/arm/common/arm_mpu_regions.c` with the correct name, base,
size and attributes gathered directly from the devicetree. See size and attributes gathered directly from the devicetree. See
:zephyr_file:`include/linker/devicetree_regions.h` for more details. :zephyr_file:`include/zephyr/linker/devicetree_regions.h` for more details.
Static MPU regions Static MPU regions
------------------ ------------------

2
doc/hardware/porting/arch.rst
View file

@ -459,7 +459,7 @@ Toolchain and Linking
Toolchain support has to be added to the build system. Toolchain support has to be added to the build system.
Some architecture-specific definitions are needed in :zephyr_file:`include/toolchain/gcc.h`. Some architecture-specific definitions are needed in :zephyr_file:`include/zephyr/toolchain/gcc.h`.
See what exists in that file for currently supported architectures. See what exists in that file for currently supported architectures.
Each architecture also needs its own linker script, even if most sections can Each architecture also needs its own linker script, even if most sections can

4
doc/kernel/data_structures/mpsc_pbuf.rst
View file

@ -82,8 +82,8 @@ Usage
Packet header definition Packet header definition
^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
Packet header details can be found in :zephyr_file:`include/sys/mpsc_packet.h`. Packet header details can be found in :zephyr_file:`include/zephyr/sys/mpsc_packet.h`.
API functions can be found in :zephyr_file:`include/sys/mpsc_pbuf.h`. Headers API functions can be found in :zephyr_file:`include/zephyr/sys/mpsc_pbuf.h`. Headers
are split to avoid include spam when declaring the packet. are split to avoid include spam when declaring the packet.
User header structure must start with internal header: User header structure must start with internal header:

2
doc/kernel/data_structures/ring_buffers.rst
View file

@ -382,6 +382,6 @@ Related configuration options:
API Reference API Reference
************* *************
The following ring buffer APIs are provided by :zephyr_file:`include/sys/ring_buffer.h`: The following ring buffer APIs are provided by :zephyr_file:`include/zephyr/sys/ring_buffer.h`:
.. doxygengroup:: ring_buffer_apis .. doxygengroup:: ring_buffer_apis

2
doc/kernel/services/other/fatal.rst
View file

@ -15,7 +15,7 @@ Runtime Assertions
Zephyr provides some macros to perform runtime assertions which may be Zephyr provides some macros to perform runtime assertions which may be
conditionally compiled. Their definitions may be found in conditionally compiled. Their definitions may be found in
:zephyr_file:`include/sys/__assert.h`. :zephyr_file:`include/zephyr/sys/__assert.h`.
Assertions are enabled by setting the ``__ASSERT_ON`` preprocessor symbol to a Assertions are enabled by setting the ``__ASSERT_ON`` preprocessor symbol to a
non-zero value. There are two ways to do this: non-zero value. There are two ways to do this:

2
doc/kernel/usermode/memory_domain.rst
View file

@ -439,6 +439,6 @@ Related configuration options:
API Reference API Reference
************* *************
The following memory domain APIs are provided by :zephyr_file:`include/kernel.h`: The following memory domain APIs are provided by :zephyr_file:`include/zephyr/kernel.h`:
.. doxygengroup:: mem_domain_apis .. doxygengroup:: mem_domain_apis

6
doc/kernel/usermode/syscalls.rst
View file

@ -250,7 +250,7 @@ passed in. This includes:
* Any other arguments that have a limited range of valid values. * Any other arguments that have a limited range of valid values.
Verification functions involve a great deal of boilerplate code which has been Verification functions involve a great deal of boilerplate code which has been
made simpler by some macros in :zephyr_file:`include/syscall_handler.h`. made simpler by some macros in :zephyr_file:`include/zephyr/syscall_handler.h`.
Verification functions should be declared using these macros. Verification functions should be declared using these macros.
Argument Validation Argument Validation
@ -608,7 +608,7 @@ APIs
**** ****
Helper macros for creating system call verification functions are provided in Helper macros for creating system call verification functions are provided in
:zephyr_file:`include/syscall_handler.h`: :zephyr_file:`include/zephyr/syscall_handler.h`:
* :c:macro:`Z_SYSCALL_OBJ()` * :c:macro:`Z_SYSCALL_OBJ()`
* :c:macro:`Z_SYSCALL_OBJ_INIT()` * :c:macro:`Z_SYSCALL_OBJ_INIT()`
@ -622,7 +622,7 @@ Helper macros for creating system call verification functions are provided in
* :c:macro:`Z_SYSCALL_VERIFY` * :c:macro:`Z_SYSCALL_VERIFY`
Functions for invoking system calls are defined in Functions for invoking system calls are defined in
:zephyr_file:`include/syscall.h`: :zephyr_file:`include/zephyr/syscall.h`:
* :c:func:`_arch_syscall_invoke0` * :c:func:`_arch_syscall_invoke0`
* :c:func:`_arch_syscall_invoke1` * :c:func:`_arch_syscall_invoke1`

4
doc/services/debugging/coredump.rst
View file

@ -240,7 +240,7 @@ The file header consists of the following fields:
- ``unsigned int`` - ``unsigned int``
- Reason for the fatal error, as the same in - Reason for the fatal error, as the same in
``enum k_fatal_error_reason`` defined in ``enum k_fatal_error_reason`` defined in
:zephyr_file:`include/fatal.h` :zephyr_file:`include/zephyr/fatal.h`
Architecture-specific Block Architecture-specific Block
--------------------------- ---------------------------
@ -311,7 +311,7 @@ dumping routine and parser for new targets. To add a new target,
the following needs to be done: the following needs to be done:
#. Add a new target code to the ``enum coredump_tgt_code`` in #. Add a new target code to the ``enum coredump_tgt_code`` in
:zephyr_file:`include/debug/coredump.h`. :zephyr_file:`include/zephyr/debug/coredump.h`.
#. Implement :c:func:`arch_coredump_tgt_code_get` simply to return #. Implement :c:func:`arch_coredump_tgt_code_get` simply to return
the newly introduced target code. the newly introduced target code.
#. Implement :c:func:`arch_coredump_info_dump` to construct #. Implement :c:func:`arch_coredump_info_dump` to construct

8
doc/services/logging/index.rst
View file

@ -66,7 +66,7 @@ time filtering is independent for each backend and each source of log messages.
Source of log messages can be a module or specific instance of the module. Source of log messages can be a module or specific instance of the module.
There are four severity levels available in the system: error, warning, info There are four severity levels available in the system: error, warning, info
and debug. For each severity level the logging API (:zephyr_file:`include/logging/log.h`) and debug. For each severity level the logging API (:zephyr_file:`include/zephyr/logging/log.h`)
has set of dedicated macros. Logger API also has macros for logging data. has set of dedicated macros. Logger API also has macros for logging data.
For each level following set of macros are available: For each level following set of macros are available:
@ -335,7 +335,7 @@ Controlling the logging
======================= =======================
Logging can be controlled using API defined in Logging can be controlled using API defined in
:zephyr_file:`include/logging/log_ctrl.h`. Logger must be initialized before it can be :zephyr_file:`include/zephyr/logging/log_ctrl.h`. Logger must be initialized before it can be
used. Optionally, user can provide function which returns timestamp value. If used. Optionally, user can provide function which returns timestamp value. If
not provided, :c:macro:`k_cycle_get_32` is used for timestamping. not provided, :c:macro:`k_cycle_get_32` is used for timestamping.
:c:func:`log_process` function is used to trigger processing of one log :c:func:`log_process` function is used to trigger processing of one log
@ -521,7 +521,7 @@ Custom Frontend
=============== ===============
Custom frontend is enabled using :kconfig:option:`CONFIG_LOG_FRONTEND`. Logs are directed Custom frontend is enabled using :kconfig:option:`CONFIG_LOG_FRONTEND`. Logs are directed
to functions declared in :zephyr_file:`include/logging/log_frontend.h`. to functions declared in :zephyr_file:`include/zephyr/logging/log_frontend.h`.
If option :kconfig:option:`CONFIG_LOG_FRONTEND_ONLY` is enabled then log message is not If option :kconfig:option:`CONFIG_LOG_FRONTEND_ONLY` is enabled then log message is not
created and no backend is handled. Otherwise, custom frontend can coexist with created and no backend is handled. Otherwise, custom frontend can coexist with
backends (not available in v1). backends (not available in v1).
@ -636,7 +636,7 @@ Message formatting
------------------ ------------------
Logging provides set of function that can be used by the backend to format a Logging provides set of function that can be used by the backend to format a
message. Helper functions are available in :zephyr_file:`include/logging/log_output.h`. message. Helper functions are available in :zephyr_file:`include/zephyr/logging/log_output.h`.
Example message formatted using :c:func:`log_output_msg_process` or Example message formatted using :c:func:`log_output_msg_process` or
:c:func:`log_output_msg2_process`. :c:func:`log_output_msg2_process`.

2
doc/services/shell/index.rst
View file

@ -118,7 +118,7 @@ Use the following macros for adding shell commands:
* :c:macro:`SHELL_DYNAMIC_CMD_CREATE` - Create a dynamic subcommands array. * :c:macro:`SHELL_DYNAMIC_CMD_CREATE` - Create a dynamic subcommands array.
Commands can be created in any file in the system that includes Commands can be created in any file in the system that includes
:zephyr_file:`include/shell/shell.h`. All created commands are available for all :zephyr_file:`include/zephyr/shell/shell.h`. All created commands are available for all
shell instances. shell instances.
Static commands Static commands

2
doc/services/storage/disk/access.rst
View file

@ -49,7 +49,7 @@ The SD card will be automatically detected and initialized by the
filesystem driver when the board boots. filesystem driver when the board boots.
To read and write files and directories, see the :ref:`file_system_api` in To read and write files and directories, see the :ref:`file_system_api` in
:zephyr_file:`include/fs/fs.h` such as :c:func:`fs_open()`, :zephyr_file:`include/zephyr/fs/fs.h` such as :c:func:`fs_open()`,
:c:func:`fs_read()`, and :c:func:`fs_write()`. :c:func:`fs_read()`, and :c:func:`fs_write()`.
Disk Access API Configuration Options Disk Access API Configuration Options

2
doc/services/tracing/index.rst
View file

@ -21,7 +21,7 @@ that has implied:
6. Writing custom ad-hoc tools for filtering and presentation. 6. Writing custom ad-hoc tools for filtering and presentation.
An application can use one of the existing formats or define a custom format by An application can use one of the existing formats or define a custom format by
overriding the macros declared in :zephyr_file:`include/tracing/tracing.h`. overriding the macros declared in :zephyr_file:`include/zephyr/tracing/tracing.h`.
Different formats, transports and host tools are available and supported in Different formats, transports and host tools are available and supported in
Zephyr. Zephyr.

4
doc/services/usb/hid.rst
View file

@ -4,8 +4,8 @@ USB Human Interface Devices (HID) support
######################################### #########################################
Since the USB HID specification is not only used by the USB subsystem, the USB HID API Since the USB HID specification is not only used by the USB subsystem, the USB HID API
is split into two header files :zephyr_file:`include/usb/class/hid.h` is split into two header files :zephyr_file:`include/zephyr/usb/class/hid.h`
and :zephyr_file:`include/usb/class/usb_hid.h`. The second includes a specific and :zephyr_file:`include/zephyr/usb/class/usb_hid.h`. The second includes a specific
part for HID support in the USB device stack. part for HID support in the USB device stack.
HID Item helpers HID Item helpers

2
doc/services/usb/udc.rst
View file

@ -5,7 +5,7 @@ USB device controller driver
The USB Device Controller Driver Layer implements the low level control routines The USB Device Controller Driver Layer implements the low level control routines
to deal directly with the hardware. All device controller drivers should to deal directly with the hardware. All device controller drivers should
implement the APIs described in :zephyr_file:`include/drivers/usb/usb_dc.h`. implement the APIs described in :zephyr_file:`include/zephyr/drivers/usb/usb_dc.h`.
This allows the integration of new USB device controllers to be done without This allows the integration of new USB device controllers to be done without
changing the upper layers. changing the upper layers.
With this API it is not possible to support more than one controller With this API it is not possible to support more than one controller

2
doc/services/usb/uds.rst
View file

@ -16,7 +16,7 @@ over time. It provides the following functionalities:
revision 2.0. revision 2.0.
* Provides a programming interface to be used by USB device classes or * Provides a programming interface to be used by USB device classes or
customer applications. The APIs is described in customer applications. The APIs is described in
:zephyr_file:`include/usb/usb_device.h` :zephyr_file:`include/zephyr/usb/usb_device.h`
The device stack has few limitations with which it is not possible to support The device stack has few limitations with which it is not possible to support
more than one controller instance at runtime, and only one USB device more than one controller instance at runtime, and only one USB device

2
samples/basic/blinky/README.rst
View file

@ -87,7 +87,7 @@ Tips:
- If you're not sure what to do, check the devicetrees for supported boards which - If you're not sure what to do, check the devicetrees for supported boards which
use the same SoC as your target. See :ref:`get-devicetree-outputs` for details. use the same SoC as your target. See :ref:`get-devicetree-outputs` for details.
- See :zephyr_file:`include/dt-bindings/gpio/gpio.h` for the flags you can use - See :zephyr_file:`include/zephyr/dt-bindings/gpio/gpio.h` for the flags you can use
in devicetree. in devicetree.
- If the LED is built in to your board hardware, the alias should be defined in - If the LED is built in to your board hardware, the alias should be defined in