systemd中文文档

- 启动: http://systemd.cn/docs/Booting/
- 自动启动评估: http://systemd.cn/docs/Booting/AUTOMATIC_BOOT_ASSESSMENT/
- 启动组件和根文件系统探测: http://systemd.cn/docs/Booting/ROOTFS_DISCOVERY/
- 引导加载程序接口: http://systemd.cn/docs/Booting/BOOT_LOADER_INTERFACE/
- 恢复出厂设置: http://systemd.cn/docs/Booting/FACTORY_RESET/
- 挂载点可用性要求: http://systemd.cn/docs/Booting/MOUNT_REQUIREMENTS/
- TPM2 PCR测量: http://systemd.cn/docs/Booting/TPM2_PCR_MEASUREMENTS/
- Boot Loader Specification: http://systemd.cn/docs/BOOT_LOADER_SPECIFICATION/
- Discoverable Partitions: http://systemd.cn/docs/DISCOVERABLE_PARTITIONS/
- Elf Dlopen Metadata: http://systemd.cn/docs/ELF_DLOPEN_METADATA/
- Osc Context: http://systemd.cn/docs/OSC_CONTEXT/
- Package Metadata for Executable Files: http://systemd.cn/docs/PACKAGE_METADATA_FOR_EXECUTABLE_FILES/
- API File Systems: http://systemd.cn/docs/API_FILE_SYSTEMS/
- Appstream Bundle: http://systemd.cn/docs/APPSTREAM_BUNDLE/
- Backports: http://systemd.cn/docs/BACKPORTS/
- Booting Without /usr is Broken: http://systemd.cn/docs/SEPARATE_USR_IS_BROKEN/
- Code Quality Tools: http://systemd.cn/docs/CODE_QUALITY/
- Coding Style: http://systemd.cn/docs/CODING_STYLE/
- Compatibility with SysV: http://systemd.cn/docs/INCOMPATIBILITIES/
- Container Interface: http://systemd.cn/docs/CONTAINER_INTERFACE/
- Contributing: http://systemd.cn/docs/CONTRIBUTING/
- Control Group APIs and Delegation: http://systemd.cn/docs/CGROUP_DELEGATION/
- Converting Existing Users to systemd-homed: http://systemd.cn/docs/CONVERTING_TO_HOMED/
- Credentials: http://systemd.cn/docs/CREDENTIALS/
- Desktop Environment Integration: http://systemd.cn/docs/DESKTOP_ENVIRONMENTS/
- Diagnosing Boot Problems: http://systemd.cn/docs/DEBUGGING/
- File Descriptor Store: http://systemd.cn/docs/FILE_DESCRIPTOR_STORE/
- Frequently Asked Questions: http://systemd.cn/docs/FAQ/
- Governance: http://systemd.cn/docs/GOVERNANCE/
- Hacking on systemd: http://systemd.cn/docs/HACKING/
- Home Directories: http://systemd.cn/docs/HOME_DIRECTORY/
- Inhibitor Locks: http://systemd.cn/docs/INHIBITOR_LOCKS/
- Initrd Interface: http://systemd.cn/docs/INITRD_INTERFACE/
- Journal Export Formats: http://systemd.cn/docs/JOURNAL_EXPORT_FORMATS/
- Journal File Format: http://systemd.cn/docs/JOURNAL_FILE_FORMAT/
- Journal Message Catalogs: http://systemd.cn/docs/CATALOG/
- JSON Group Records: http://systemd.cn/docs/GROUP_RECORD/
- JSON User Records: http://systemd.cn/docs/USER_RECORD/
- Known Environment Variables: http://systemd.cn/docs/ENVIRONMENT/
- Locking Block Device Access: http://systemd.cn/docs/BLOCK_DEVICE_LOCKING/
- Minimal Builds: http://systemd.cn/docs/MINIMAL_BUILDS/
- My Service Can't Get Realtime!: http://systemd.cn/docs/MY_SERVICE_CANT_GET_REALTIME/
- Native Journal Protocol: http://systemd.cn/docs/JOURNAL_NATIVE_PROTOCOL/
- New Control Group Interfaces: http://systemd.cn/docs/CONTROL_GROUP_INTERFACE/
- Notes for Translators: http://systemd.cn/docs/TRANSLATORS/
- Password Agents: http://systemd.cn/docs/PASSWORD_AGENTS/
- Pax Controla Groupiana: http://systemd.cn/docs/PAX_CONTROL_GROUPS/
- Portability and Stability: http://systemd.cn/docs/PORTABILITY_AND_STABILITY/
- Portable Services Introduction: http://systemd.cn/docs/PORTABLE_SERVICES/
- Porting systemd To New Distributions: http://systemd.cn/docs/DISTRO_PORTING/
- Porting to New Architectures: http://systemd.cn/docs/PORTING_TO_NEW_ARCHITECTURES/
- Predictable Network Interface Names: http://systemd.cn/docs/PREDICTABLE_INTERFACE_NAMES/
- Presets: http://systemd.cn/docs/PRESET/
- Project IDs for Disk Quotas on Exec Directories: http://systemd.cn/docs/DISK-QUOTAS-PROJECTIDS/
- Random Seeds: http://systemd.cn/docs/RANDOM_SEEDS/
- Reporting of Security Vulnerabilities: http://systemd.cn/docs/SECURITY/
- Resource Pressure Handling: http://systemd.cn/docs/PRESSURE/
- Running Services After the Network Is Up: http://systemd.cn/docs/NETWORK_ONLINE/
- Safely Building Images: http://systemd.cn/docs/BUILDING_IMAGES/
- Socket Activation with Popular Daemons: http://systemd.cn/docs/DAEMON_SOCKET_ACTIVATION/
- Steps to a Successful Release: http://systemd.cn/docs/RELEASE/
- Storage Daemons for the Root File System: http://systemd.cn/docs/ROOT_STORAGE_DAEMONS/
- systemd Community Conduct Guidelines: http://systemd.cn/docs/CODE_OF_CONDUCT/
- systemd Coredump Handling: http://systemd.cn/docs/COREDUMP/
- systemd File Hierarchy Requirements: http://systemd.cn/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS/
- systemd Optimizations: http://systemd.cn/docs/OPTIMIZATIONS/
- systemd Repository Architecture: http://systemd.cn/docs/ARCHITECTURE/
- systemd-boot UEFI Boot Manager: http://systemd.cn/docs/BOOT/
- systemd-homed and JSON User/Group Record Support in Desktop Environments: http://systemd.cn/docs/USERDB_AND_DESKTOPS/
- systemd-resolved and VPNs: http://systemd.cn/docs/RESOLVED-VPNS/
- Testing systemd Using Sanitizers: http://systemd.cn/docs/TESTING_WITH_SANITIZERS/
- The Case for the /usr Merge: http://systemd.cn/docs/THE_CASE_FOR_THE_USR_MERGE/
- Tips And Tricks: http://systemd.cn/docs/TIPS_AND_TRICKS/
- User Record Blob Directories: http://systemd.cn/docs/USER_RECORD_BLOB_DIRS/
- User/Group Name Syntax: http://systemd.cn/docs/USER_NAMES/
- User/Group Record Lookup API via Varlink: http://systemd.cn/docs/USER_GROUP_API/
- Users, Groups, UIDs and GIDs on systemd Systems: http://systemd.cn/docs/UIDS-GIDS/
- Using /tmp/ and /var/tmp/ Safely: http://systemd.cn/docs/TEMPORARY_DIRECTORIES/
- Varlink API Style: http://systemd.cn/docs/VARLINK/
- VM Interface: http://systemd.cn/docs/VM_INTERFACE/
- What Settings Are Currently Available For Transient Units?: http://systemd.cn/docs/TRANSIENT-SETTINGS/
- Writing Desktop Environments: http://systemd.cn/docs/WRITING_DESKTOP_ENVIRONMENTS/
- Writing Display Managers: http://systemd.cn/docs/WRITING_DISPLAY_MANAGERS/
- Writing Network Configuration Managers: http://systemd.cn/docs/WRITING_NETWORK_CONFIGURATION_MANAGERS/
- Writing Resolver Clients: http://systemd.cn/docs/WRITING_RESOLVER_CLIENTS/
- Writing syslog Daemons Which Cooperate Nicely With systemd: http://systemd.cn/docs/SYSLOG/
- Writing VM and Container Managers: http://systemd.cn/docs/WRITING_VM_AND_CONTAINER_MANAGERS/


# General guideline

- Varlink field names should use camelCase. This guideline does not apply to
  well-known and documented configuration options, such as those defined in
  [systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html),
  where existing naming conventions should be preserved for
  compatibility and clarity.

- Every field and method should include meaningful documentation. It's
  acceptable to reference existing documentation where appropriate.
  Documentation may be omitted only when the meaning is self-evident, even to
  someone not already familiar with varlink interface/method.

- Varlink fields should optimize toward clarity:
  * avoid abbreviations: `cacheDir` -> `cacheDirectory`
  * prefer string values over numeric codes when possible,
    to make interfaces more self-descriptive and easier to understand.

# Interface structure

- Varlink methods should consider splitting their output into 'context' and
  'runtime' sections. The guiding principle is simple: if a property makes
  sense to include in a configuration (e.g. unit file), it belongs to 'context';
  otherwise, it goes under 'runtime'. This split ensures a consistent and
  reusable structure. Functions that describe an object can produce context
  data that other functions can later consume to create a similar object.

  Example: `io.systemd.Unit.List` outputs unit configuration, which can later
  be reused to create another unit via `io.systemd.Unit.StartTransient` (not
  implemented yet). The `io.systemd.Unit.StartTransient` call should accept
  only the 'context' portion of the output, without requiring any runtime data
  such as state (e.g. pid) or statistics.

- Following the guideline above, any field within 'context' should be nullable
  by default. This ensures that when a context structure is used as input, the
  caller is not required to provide every field explicitly. Omitted fields are
  automatically assigned their default values, allowing partial context
  definitions to be valid and simplifying reuse across different operations.
  Fields that cannot logically be omitted in input (e.g. a unit type) may remain
  non-nullable.

# Enums

- Enum fields in the codebase must be exposed as string values in Varlink, not
  as their underlying integer representations. Use `SD_VARLINK_DEFINE_ENUM_TYPE`
  to declare an enum type in the Varlink specification.

- The Varlink IDL validator does not permit enum values that contain dashes.
  Therefore, when defining an enum for Varlink, replace dashes with underscores.

- Varlink interface should output enum values using the underscore form. For
  input, it should accept both the original dash-containing form and the
  underscore form. The following helpers simplify this:
  * `JSON_BUILD_STRING_UNDERSCORIFY` - outputs a stringified enum value
    with dashes converted to underscores.
  * `JSON_DISPATCH_ENUM_DEFINE` - creates a `json_dispatch_*` function that
    accepts both the original and the underscorified enum value as valid input.

  For example, a `LogTarget` field outputs `"journal_or_kmsg"` (underscore
  form), but on input both `"journal_or_kmsg"` and `"journal-or-kmsg"` are
  accepted. This is handled automatically by `JSON_DISPATCH_ENUM_DEFINE`:
  it first tries the value as-is via `_from_string()`, and if that fails,
  replaces underscores with dashes and retries.

- An internal enum may be exposed as a simple string field instead of a Varlink
  enum type when the field is output-only and never provided or controlled by
  the user. However, such fields should avoid using dashes to prevent breaking
  changes if they are later converted into enums (see below).

  For example, in `io.systemd.Unit`, configuration settings that users select
  in unit files (e.g. `ProtectSystem`, `ExecInputType`) should be proper varlink
  enum types. Runtime state fields that only the engine determines (e.g.
  `ActiveState`, `SubState`) may remain plain strings.

- A varlink string field that has a finite set of possible values may later be
  converted into an enum without introducing a breaking change. This allows the
  interface to evolve from loosely defined string values to a more explicit and
  type-safe enumeration once the valid options are well established.