doc(guidelines): adapt to the new API design

Author: yvt

doc/guidelines.md

@@ -61,17 +61,15 @@ Exceptions:
 
 ### Optional features should be documented properly (CC-DOC-OPT-FEATURES)
 
-All optional features of `r3` must be listed and explained in the crate-level documentation.
+All optional features of `r3` and `r3_kernel` must be listed and explained in the crate-level documentation.
 
 In addition, every public item gated by such features must have [`#[doc(cfg(feature = ...))]` attribute](https://github.com/rust-lang/rust/issues/43781), which displays the required feature on the generated documentation.
 
 ```rust
-/// Get the current [system time].
-///
-/// [system time]: crate#kernel-timing
+/// Get the current system time.
 #[cfg(feature = "system_time")]
 #[doc(cfg(feature = "system_time"))]
-fn time() -> Result<Time, TimeError>;
+pub fn time() -> Result<Time, TimeError>;
 ```
 
 ## Testing
@@ -107,18 +105,18 @@ The runtime overhead caused by unused features should be minimized or eliminated
 
   Example: If no startup hooks are defined, the compiler will simply remove the startup hook initialization loop because it can figure out that `STARTUP_HOOKS` has no elements.
 
-- If the usage of such features can be detected statically in a configuration macro (e.g., `r3::build!`), the macro should control the type choices based on that.
+- If the usage of such features can be detected statically in a configuration macro (e.g., `r3_kernel::build!`), the macro should control the type choices based on that.
 
   Examples:
 
   - `r3_portkit::tickful::TickfulState` (used by timer drivers) chooses the optimal algorithm based on parameters.
 
   - Kernel objects are defined statically and their control blocks are stored in static arrays.
 
-- If the above options are infeasible, expose either a `CfgBuilder` method or a Cargo feature to let downstream crates and application developers specify whether a feature should be compiled in.
+- If the above options are infeasible, expose either a method in `Cfg` or a Cargo feature to let downstream crates and application developers specify whether a feature should be compiled in.
 
   Examples:
 
   - The system clock is controlled by `system_time` feature. The system time is tracked by an internal variable that is updated on timer interrupts, and there's no hope of the compiler optimizing this out. It's impossible for `build!` to detect the usage of `System::time()`. The system clock is not tied to any particular kernel objects, so the software components dependent on the system clock might not have a configuration function. On the other hand, Cargo features are designed exactly for this use case.
 
-  - Application code can change task priorities at runtime. The maximum (lowest) priority affects the size of internal kernel structures, but it's impossible for `build!` to figure that out. Therefore, `CfgBuilder` exposes `num_task_priority_levels` method.
+  - Application code can change task priorities at runtime. The maximum (lowest) priority affects the size of internal kernel structures, but it's impossible for `build!` to figure that out. Therefore, `Cfg` exposes `num_task_priority_levels` method.