Rename "SDK" -> "Developer Tools" in documentations (OSS files) (#5238)

Olivia-liu · facebook-github-bot · commit 6328d41eb87e · 2024-09-11T14:32:32.000-07:00
Summary: Pull Request resolved: #5238 Part of the bigger "sdk" rename to "devtools" task, context in [post](https://fb.workplace.com/groups/222849770514616/permalink/467450562721201/). This diff replaces "SDK" with "Developer Tools" in the documentations. Reviewed By: dbort Differential Revision: D62462792 fbshipit-source-id: 18a46779a9e6d7fb782f563fe73f7c612afc4838
diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -197,7 +197,7 @@ option(EXECUTORCH_BUILD_KERNELS_OPTIMIZED "Build the optimized kernels" OFF)
 
 option(EXECUTORCH_BUILD_KERNELS_QUANTIZED "Build the quantized kernels" OFF)
 
-option(EXECUTORCH_BUILD_SDK "Build the ExecuTorch SDK")
+option(EXECUTORCH_BUILD_SDK "Build the ExecuTorch Developer Tools")
 
 option(EXECUTORCH_BUILD_SIZE_TEST "Build the size test" OFF)
 
diff --git a/README.md b/README.md
@@ -10,9 +10,9 @@ Key value propositions of ExecuTorch are:
 - **Portability:** Compatibility with a wide variety of computing platforms,
   from high-end mobile phones to highly constrained embedded systems and
   microcontrollers.
-- **Productivity:** Enabling developers to use the same toolchains and SDK from
-  PyTorch model authoring and conversion, to debugging and deployment to a wide
-  variety of platforms.
+- **Productivity:** Enabling developers to use the same toolchains and Developer
+  Tools from PyTorch model authoring and conversion, to debugging and deployment
+  to a wide variety of platforms.
 - **Performance:** Providing end users with a seamless and high-performance
   experience due to a lightweight runtime and utilizing full hardware
   capabilities such as CPUs, NPUs, and DSPs.
diff --git a/devtools/debug_format/base_schema.py b/devtools/debug_format/base_schema.py
@@ -4,8 +4,10 @@
 # This source code is licensed under the BSD-style license found in the
 # LICENSE file in the root directory of this source tree.
 
+# pyre-unsafe
+
 """
-Base Intermediate Representation for Productivity SDK consumers
+Base Intermediate Representation for Developer Tools consumers
 (e.g. TensorBoard, Terminal Debugger)
 """
 
diff --git a/devtools/debug_format/et_schema.py b/devtools/debug_format/et_schema.py
@@ -4,8 +4,10 @@
 # This source code is licensed under the BSD-style license found in the
 # LICENSE file in the root directory of this source tree.
 
+# pyre-unsafe
+
 """
-Intermediate Representation of ExecuTorch Concepts in Productivity SDK
+Intermediate Representation of ExecuTorch Concepts in Developer Tools
 """
 
 from __future__ import annotations
diff --git a/devtools/etrecord/_etrecord.py b/devtools/etrecord/_etrecord.py
@@ -4,6 +4,8 @@
 # This source code is licensed under the BSD-style license found in the
 # LICENSE file in the root directory of this source tree.
 
+# pyre-unsafe
+
 import json
 import os
 import pickle
@@ -182,7 +184,7 @@ def generate_etrecord(
     is the closest graph module representation of what is eventually run on the device.
     In addition to all the graph modules, we also serialize the program buffer, which the users
     can provide to the ExecuTorch runtime to run the model, and the debug handle map
-    for SDK tooling usage.
+    for Developer Tools usage.
 
     Args:
         et_record: Path to where the `ETRecord` file will be saved to.
@@ -201,7 +203,7 @@ def generate_etrecord(
 
     etrecord_zip = ZipFile(et_record, "w")
     # Write the magic file identifier that will be used to verify that this file
-    # is an etrecord when it's used later in the SDK tooling.
+    # is an etrecord when it's used later in the Developer Tools.
     etrecord_zip.writestr(ETRecordReservedFileNames.ETRECORD_IDENTIFIER, "")
 
     if export_modules is not None:
diff --git a/devtools/etrecord/tests/etrecord_test.py b/devtools/etrecord/tests/etrecord_test.py
@@ -4,6 +4,8 @@
 # This source code is licensed under the BSD-style license found in the
 # LICENSE file in the root directory of this source tree.
 
+# pyre-unsafe
+
 import copy
 import json
 import tempfile
@@ -75,7 +77,7 @@ def get_test_model_with_manager(self):
         return (aten_dialect, edge_program_copy, edge_program.to_executorch())
 
     # Serialized and deserialized graph modules are not completely the same, so we check
-    # that they are close enough and match especially on the parameters we care about in the SDK.
+    # that they are close enough and match especially on the parameters we care about in the Developer Tools.
     def check_graph_closeness(self, graph_a, graph_b):
         self.assertEqual(len(graph_a.graph.nodes), len(graph_b.graph.nodes))
         for node_a, node_b in zip(graph_a.graph.nodes, graph_b.graph.nodes):
diff --git a/docs/source/compiler-delegate-and-partitioner.md b/docs/source/compiler-delegate-and-partitioner.md
@@ -127,13 +127,13 @@ static auto success_with_compiler = register_backend(backend);
 ```
 
 
-## SDK Integration: Debuggability
+## Developer Tools Integration: Debuggability
 
-Providing consistent debugging experience, be it for runtime failures or performance profiling, is important. ExecuTorch employs native SDK (Software Development Kit) for this purpose, which enables correlating program instructions to original PyTorch code, via debug handles. You can read more about it [here](./sdk-etrecord).
+Providing consistent debugging experience, be it for runtime failures or performance profiling, is important. ExecuTorch employs native Developer Tools for this purpose, which enables correlating program instructions to original PyTorch code, via debug handles. You can read more about it [here](./sdk-etrecord).
 
-Delegated program or subgraphs are opaque to ExecuTorch runtime and appear as a special `call_delegate` instruction, which asks corresponding backend to handle the execution of the subgraph or program. Due to the opaque nature of backend delgates, native SDK does not have visibility into delegated program. Thus the debugging, functional or performance, experiences of delegated execution suffers significantly as compared to it's non-delegated counterpart.
+Delegated program or subgraphs are opaque to ExecuTorch runtime and appear as a special `call_delegate` instruction, which asks corresponding backend to handle the execution of the subgraph or program. Due to the opaque nature of backend delgates, native Developer Tools does not have visibility into delegated program. Thus the debugging, functional or performance, experiences of delegated execution suffers significantly as compared to it's non-delegated counterpart.
 
-In order to provide consistent debugging experience to users, regardless of the use of delegation for a model, SDK provides an interface to correlate delegated (sub)graph to original (sub)graph. The SDK does so via debug handles map which allows delegates to generate internal handles that can be associated with the original (sub)graph consumed by the delegate. Then at runtime, backend developer can report error or profiling information using the internal handle, which will be mapped to original (sub)graph using the debug handle map. For more information, please refer to [SDK delegate integration](./sdk-delegate-integration).
+In order to provide consistent debugging experience to users, regardless of the use of delegation for a model, Developer Tools provide an interface to correlate delegated (sub)graph to original (sub)graph. The Developer Tools do so via debug handles map which allows delegates to generate internal handles that can be associated with the original (sub)graph consumed by the delegate. Then at runtime, backend developer can report error or profiling information using the internal handle, which will be mapped to original (sub)graph using the debug handle map. For more information, please refer to [Developer Tools Delegate Integration](./sdk-delegate-integration).
 
 By leveraging the debug identifier, backend developer can embed the debug as part of the delegated blob
 
diff --git a/docs/source/concepts.md b/docs/source/concepts.md
@@ -283,9 +283,9 @@ Techniques for performing computations and memory accesses on tensors with lower
 
 The ExecuTorch runtime executes models on edge devices. It is responsible for program initialization, program execution and, optionally, destruction (releasing backend owned resources).
 
-## [SDK](./sdk-overview.md)
+## [Developer Tools](./sdk-overview.md)
 
-Software Development Kit. The tooling users need to profile, debug and visualize programs that are running with ExecuTorch.
+A collection of tools users need to profile, debug and visualize programs that are running with ExecuTorch.
 
 ## [Selective build](./kernel-library-selective-build.md)
 
diff --git a/docs/source/getting-started-architecture.md b/docs/source/getting-started-architecture.md
@@ -87,8 +87,8 @@ The ExecuTorch runtime is written in C++ with minimal dependencies for portabili
 
 _Executor_ is the entry point to load the program and execute it. The execution triggers corresponding operator kernels or backend execution from this very minimal runtime.
 
-## SDK
+## Developer Tools
 
-It should be efficient for users to go from research to production using the flow above. Productivity is essentially important, for users to author, optimize and deploy their models. We provide [ExecuTorch SDK](./sdk-overview.md) to improve productivity. The SDK is not in the diagram. Instead it's a tool set that covers the developer workflow in all three phases.
+It should be efficient for users to go from research to production using the flow above. Productivity is essentially important, for users to author, optimize and deploy their models. We provide [ExecuTorch Developer Tools](./sdk-overview.md) to improve productivity. The Developer Tools are not in the diagram. Instead it's a tool set that covers the developer workflow in all three phases.
 
-During the program preparation and execution, users can use the ExecuTorch SDK to profile, debug, or visualize the program. Since the end-to-end flow is within the PyTorch ecosystem, users can correlate and display performance data along with graph visualization as well as direct references to the program source code and model hierarchy. We consider this to be a critical component for quickly iterating and lowering PyTorch programs to edge devices and environments.
+During the program preparation and execution, users can use the ExecuTorch Developer Tools to profile, debug, or visualize the program. Since the end-to-end flow is within the PyTorch ecosystem, users can correlate and display performance data along with graph visualization as well as direct references to the program source code and model hierarchy. We consider this to be a critical component for quickly iterating and lowering PyTorch programs to edge devices and environments.
diff --git a/docs/source/index.rst b/docs/source/index.rst
@@ -193,7 +193,7 @@ Topics in this section will help you get started with ExecuTorch.
 .. toctree::
    :glob:
    :maxdepth: 1
-   :caption: SDK
+   :caption: Developer Tools
    :hidden:
 
    sdk-overview
@@ -244,11 +244,11 @@ ExecuTorch tutorials.
    :tags:
 
 .. customcarditem::
-   :header: Using the ExecuTorch SDK to Profile a Model
-   :card_description: A tutorial for using the ExecuTorch SDK to profile and analyze a model with linkage back to source code.
+   :header: Using the ExecuTorch Developer Tools to Profile a Model
+   :card_description: A tutorial for using the ExecuTorch Developer Tools to profile and analyze a model with linkage back to source code.
    :image: _static/img/generic-pytorch-logo.png
    :link: tutorials/sdk-integration-tutorial.html
-   :tags: SDK
+   :tags: devtools
 
 .. customcarditem::
    :header: Integrating and Running ExecuTorch on Apple Platforms
diff --git a/docs/source/intro-overview.md b/docs/source/intro-overview.md
@@ -10,9 +10,9 @@ Key value propositions of ExecuTorch are:
 - **Portability:** Compatibility with a wide variety of computing platforms,
   from high-end mobile phones to highly constrained embedded systems and
   microcontrollers.
-- **Productivity:** Enabling developers to use the same toolchains and SDK from
-  PyTorch model authoring and conversion, to debugging and deployment to a wide
-  variety of platforms.
+- **Productivity:** Enabling developers to use the same toolchains and Developer
+  Tools from PyTorch model authoring and conversion, to debugging and deployment
+  to a wide variety of platforms.
 - **Performance:** Providing end users with a seamless and high-performance
   experience due to a lightweight runtime and utilizing full hardware
   capabilities such as CPUs, NPUs, and DSPs.
diff --git a/docs/source/llm/getting-started.md b/docs/source/llm/getting-started.md
@@ -746,7 +746,7 @@ In the fragment of the output for nanoGPT below, observe that embedding and add
 
 ### Performance Analysis
 
-Through the ExecuTorch SDK, users are able to profile model execution, giving timing information for each operator in the model.
+Through the ExecuTorch Developer Tools, users are able to profile model execution, giving timing information for each operator in the model.
 
 #### Prerequisites
 
@@ -805,7 +805,7 @@ if (result.buf != nullptr && result.size > 0) {
 }
 ```
 
-Additionally, update CMakeLists.txt to build with SDK and enable events to be traced and logged into ETDump:
+Additionally, update CMakeLists.txt to build with Developer Tools and enable events to be traced and logged into ETDump:
 
 ```
 option(EXECUTORCH_BUILD_SDK "" ON)
diff --git a/docs/source/native-delegates-executorch-xnnpack-delegate.md b/docs/source/native-delegates-executorch-xnnpack-delegate.md
@@ -74,7 +74,7 @@ Since weight packing creates an extra copy of the weights inside XNNPACK, We fre
 When executing the XNNPACK subgraphs, we prepare the tensor inputs and outputs and feed them to the XNNPACK runtime graph. After executing the runtime graph, the output pointers are filled with the computed tensors.
 
 #### **Profiling**
-We have enabled basic profiling for XNNPACK delegate that can be enabled with the following compiler flag `-DENABLE_XNNPACK_PROFILING`. With ExecuTorch's SDK integration, you can also now use the SDK tools to profile the model. You can follow the steps in [Using the ExecuTorch SDK to Profile a Model](./tutorials/sdk-integration-tutorial) on how to profile ExecuTorch models and use SDK's Inspector API to view XNNPACK's internal profiling information.
+We have enabled basic profiling for XNNPACK delegate that can be enabled with the following compiler flag `-DENABLE_XNNPACK_PROFILING`. With ExecuTorch's Developer Tools integration, you can also now use the Developer Tools to profile the model. You can follow the steps in [Using the ExecuTorch Developer Tools to Profile a Model](./tutorials/sdk-integration-tutorial) on how to profile ExecuTorch models and use Developer Tools' Inspector API to view XNNPACK's internal profiling information.
 
 
 [comment]: <> (TODO: Refactor quantizer to a more official quantization doc)
diff --git a/docs/source/sdk-debugging.md b/docs/source/sdk-debugging.md
@@ -1,6 +1,6 @@
 # Debugging Models in ExecuTorch
 
-With the ExecuTorch SDK, users can debug their models for numerical inaccurcies and extract model outputs from their device to do quality analysis (such as Signal-to-Noise, Mean square error etc.).
+With the ExecuTorch Developer Tools, users can debug their models for numerical inaccurcies and extract model outputs from their device to do quality analysis (such as Signal-to-Noise, Mean square error etc.).
 
 Currently, ExecuTorch supports the following debugging flows:
 - Extraction of model level outputs via ETDump.
diff --git a/docs/source/sdk-delegate-integration.md b/docs/source/sdk-delegate-integration.md
@@ -1,4 +1,4 @@
-# SDK Delegate Integration
+# Developer Tools Delegate Integration
 
 [Delegate backends](compiler-delegate-and-partitioner.md) are a prominent component of on-device models due to their flexibility in defining behavior. A side effect of this flexibility is that it operates as an opaque transformation. This obfuscates rich associations and mutations that are valuable in post-processing.
 - For example, if two different operator fusions were to occur within a delegate, post processing wouldn’t be able to separate the two transformations.
diff --git a/docs/source/sdk-etdump.md b/docs/source/sdk-etdump.md
@@ -1,6 +1,6 @@
 # Prerequisite | ETDump - ExecuTorch Dump
 
-ETDump (ExecuTorch Dump) is one of the core components of the ExecuTorch SDK experience. It is the mechanism through which all forms of profiling and debugging data is extracted from the runtime. Users can't parse ETDump directly; instead, they should pass it into the Inspector API, which deserializes the data, offering interfaces for flexible analysis and debugging.
+ETDump (ExecuTorch Dump) is one of the core components of the ExecuTorch Developer Tools. It is the mechanism through which all forms of profiling and debugging data is extracted from the runtime. Users can't parse ETDump directly; instead, they should pass it into the Inspector API, which deserializes the data, offering interfaces for flexible analysis and debugging.
 
 
 ## Generating an ETDump
diff --git a/docs/source/sdk-etrecord.rst b/docs/source/sdk-etrecord.rst
@@ -9,7 +9,7 @@ users ahead of time (when they export their model to run on ExecuTorch).
 To draw a rough equivalent to conventional software development,
 ``ETRecord`` can be considered as the binary built with debug symbols
 that is used for debugging in GNU Debugger (gdb). It is expected that
-the user will supply this to the ExecuTorch SDK tooling in order for
+the user will supply this to the ExecuTorch Developer Tools in order for
 them to debug and visualize their model.
 
 ``ETRecord`` contains numerous components such as:
diff --git a/docs/source/sdk-overview.md b/docs/source/sdk-overview.md
diff --git a/docs/source/sdk-profiling.md b/docs/source/sdk-profiling.md
diff --git a/docs/source/sdk-tutorial.md b/docs/source/sdk-tutorial.md
diff --git a/docs/source/tutorials_source/sdk-integration-tutorial.py b/docs/source/tutorials_source/sdk-integration-tutorial.py
diff --git a/runtime/core/event_tracer.h b/runtime/core/event_tracer.h
