PR feedback

Signed-off-by: Alan Jowett <alan.jowett@microsoft.com>

Author: Alan Jowett

docs/GlobalHelperFunctionsFromExternalDrivers.md

@@ -8,53 +8,50 @@ This document outlines the requirements for enabling drivers outside of `ebpfcor
 
 The current eBPF for Windows global helper function system requires:
 - **Global helpers hosted only in `ebpfcore.sys`** limiting extensibility by third-party drivers
-- **Pre-assigned numeric IDs** for all helper functions
-- **Centralized coordination** of helper ID assignments to prevent conflicts
-- **Static ID management** making it difficult for external drivers to expose custom global helper functions
+- **Pre-coordination of helper function registration** to prevent conflicts
+- **Static management** making it difficult for external drivers to expose custom global helper functions
 
 This creates barriers for independent driver development and limits the extensibility of the eBPF ecosystem by preventing external drivers from contributing global helper functions.
 
 ## Requirements
 
 ### R1: External Driver Global Helper Registration
-- Drivers outside of `ebpfcore.sys` **MUST** be able to register global helper functions as general program information providers
-- The system **MUST** support global helper function registration using descriptive names instead of pre-assigned numeric IDs
-- Registration **MUST** use existing NMR (Network Module Registrar) interfaces without modification
-- External drivers **MUST** be able to register global helpers with `helper_id = -1` to indicate name-based registration
+- Drivers outside of `ebpfcore.sys` **MUST** be able to register global helper functions
+- The system **MUST** support global helper function registration without requiring pre-coordination
+- Registration **MUST** use existing interfaces without requiring new APIs
 
-### R2: Elimination of Central ID Coordination
-- Driver developers **MUST NOT** be required to coordinate helper function ID assignments with other drivers
+### R2: Elimination of Central Coordination
+- Driver developers **MUST NOT** be required to coordinate helper function registration with other drivers
 - The system **MUST** reject registration attempts when multiple drivers try to register helper functions with the same name
 - Helper function names **MUST** be globally unique across all registered providers
-- Helper function ID assignment **MUST** be managed automatically by the runtime
+- Helper function registration **MUST** be managed automatically by the system
 
 ### R3: Per-Program Global Helper Resolution
-- Each eBPF program **MUST** maintain its own stable mapping of global helper function names to IDs
-- Global helper function IDs **MUST** remain consistent for the lifetime of each program
-- The system **MUST** resolve global helper function names to program-specific IDs during program loading
+- Each eBPF program **MUST** have access to a consistent set of global helper functions for its lifetime
+- The system **MUST** resolve global helper function references during program loading
 - Programs **MUST** be able to access global helpers from both `ebpfcore.sys` and external drivers
 
 ### R4: Backward Compatibility
-- Existing global helper functions using numeric IDs **MUST** continue to work unchanged
+- Existing global helper functions **MUST** continue to work unchanged
 - Existing driver code **MUST NOT** require modification to continue functioning
-- The bpf2c contract **MUST** remain compatible with existing compiled programs
-- Mixed usage of named and numeric global helper functions **MUST** be supported within the same program
+- Existing compiled programs **MUST** remain compatible
+- Mixed usage of existing and new global helper functions **MUST** be supported within the same program
 
-### R5: External Function Call Support
-- eBPF programs compiled from C **MUST** be able to use external function calls that resolve to global helper functions by name
-- The bpf2c compiler **MUST** detect external function calls and mark them for name-based resolution
-- Generated native code **MUST** support both traditional helper IDs and name-based resolution for global helpers
+### R5: C Program Support
+- eBPF programs written in C **MUST** be able to call global helper functions using standard function call syntax
+- The compilation process **MUST** handle global helper function resolution transparently
+- Generated code **MUST** support global helper function calls from external drivers
 
-### R6: Multiple General Program Information Provider Support
-- eBPF programs **MUST** be able to utilize global helper functions from multiple general program information providers simultaneously
-- The system **MUST** search across all registered providers (including external drivers) when resolving global helper function names
+### R6: Multiple Provider Support
+- eBPF programs **MUST** be able to utilize global helper functions from multiple providers simultaneously
+- The system **MUST** support discovery and resolution of global helper functions across all registered providers
 - Provider lifecycle events (attach/detach) **MUST** be handled independently for each provider
 - Global helper function name conflicts between providers **MUST** be detected and rejected during registration
 
-### R7: Metadata Integrity
-- Program metadata hashing **MUST** remain consistent between compile-time and runtime for name-based global helpers
-- Hash computation **MUST** exclude helper IDs for name-based global helpers while including all other prototype information
-- Verification **MUST** ensure programs execute with the same global helper function information used during compilation
+### R7: Program Integrity
+- Programs **MUST** execute with the same global helper function information that was available during compilation
+- The system **MUST** ensure consistency between compile-time and runtime global helper function availability
+- Program verification **MUST** account for global helper functions from external drivers
 
 ## Success Criteria
 
@@ -64,13 +61,13 @@ This creates barriers for independent driver development and limits the extensib
 
 ### SC2: Developer Experience
 - eBPF program developers can use descriptive global helper function names in their C code
-- Compilation and loading processes handle name resolution transparently
-- Error messages provide clear diagnostics for unresolvable global helper function names
+- Compilation and loading processes handle global helper function resolution transparently
+- Error messages provide clear diagnostics for unavailable global helper functions
 
 ### SC3: System Stability
-- Global helper function ID assignments remain stable throughout each program's lifetime
+- Global helper function availability remains stable throughout each program's lifetime
 - Provider lifecycle events do not disrupt running programs
-- System performance is not significantly impacted by name resolution overhead
+- System performance is not significantly impacted by global helper function resolution
 
 ### SC4: Ecosystem Growth
 - Independent software vendors can develop eBPF extensions with custom global helper functions without platform dependencies
@@ -87,10 +84,14 @@ This creates barriers for independent driver development and limits the extensib
 ## Implementation Constraints
 
 - **Zero breaking changes** to existing APIs or driver interfaces
-- **Minimal code modifications** to core eBPF subsystems
-- **Preserve existing performance** characteristics for traditional numeric global helpers
+- **Minimal modifications** to core eBPF subsystems
+- **Preserve existing performance** characteristics for current global helpers
 - **Maintain security model** for global helper function access and verification
 
+## Implementation Notes
+
+While this document focuses on requirements rather than implementation details, it should be noted that BTF (BPF Type Format) IDs represent one possible mechanism that could be leveraged to implement helper function identification and resolution without requiring pre-coordination between drivers.
+
 ## Conclusion
 
 This requirements document establishes the foundation for enabling external drivers to expose global helper functions to eBPF programs, creating a more flexible and developer-friendly eBPF helper function ecosystem while maintaining complete backward compatibility and system integrity. The solution must eliminate coordination barriers for independent driver development while preserving the reliability and security of the existing eBPF platform.