Awesome Reviewers

Configuration systems should be designed with modularity and clarity in mind. When creating configuration classes or mechanisms:

1. Separate generic from specific configurations: Organize configuration options by their scope and applicability. Use class hierarchies or namespaces to isolate domain-specific settings from generic ones.

// Good practice - clear separation of concerns
class AcceleratorAllocatorConfig {
  // Common settings applicable to all accelerators
};

class CUDAAllocatorConfig : public AcceleratorAllocatorConfig {
  // CUDA-specific settings
};

1. Use descriptive, consistent naming conventions: Configuration option names should clearly indicate their purpose and scope.
   • Avoid device-specific terms in generic interfaces (e.g., use device_malloc not cudamalloc)
   • Use consistent prefixes to group related options (e.g., pinned_ for pinned memory settings)

2. Document all configuration options: Each option should have clear documentation explaining its purpose, valid values, and implications.

3. Design for extensibility: Implement hook mechanisms that allow domain-specific configurations to be integrated with generic ones.

4. Propagate build-time configurations: When generating configuration files (e.g., from .cmake.in templates), ensure build-time choices are properly encoded for downstream consumers.

These practices improve maintainability by making configuration systems more intuitive, better documented, and easier to extend for new devices or backends.

This site is open source. Improve this page.