Log Data Processing Pipeline
Relevant source files
The following files were used as context for generating this wiki page:
The Log Data Processing Pipeline in KernelForge manages the lifecycle of kernel compilation data, from real-time generation to AI-assisted analysis. It captures build output, formats it for user display in a virtual terminal, and provides an interface for diagnosing build failures using a troubleshooting assistant.
The pipeline ensures that developers can monitor compilation progress for modern Android kernels (e.g., SM8550) and identify compatibility issues related to GKI (Generic Kernel Image) or KMI (Kernel Module Interface). Sources: README.md:14-16, src/app/page.tsx:287-291
Log Ingestion and State Management
The ingestion phase starts when you initiate a build. The system uses a centralized state to store an array of log entries, each containing a unique identifier, a timestamp, a severity level, and a message string. Sources: src/app/page.tsx:81-87
The addLog function acts as the primary ingestor. It appends new messages to the logs state array. During the build process, various modules (e.g., KernelSU, SUSFS, NoMount) push success or info messages to this pipeline. Sources: src/app/page.tsx:94-118
Log Entry Data Structure
Each log entry follows a specific interface used for both storage and rendering.
| Field | Type | Description |
|---|---|---|
id | string | Unique identifier generated via Math.random() |
timestamp | string | Local time when the log was captured |
level | string | Severity: info, error, warning, or success |
message | string | The raw text output from the build process |
Sources: src/components/dashboard/KernelLogs.tsx:6-11, src/app/page.tsx:82-87
Real-time Log Visualization
The KernelLogs component renders the ingested data in a terminal-like interface. It monitors the logs array and automatically scrolls to the bottom as new data arrives to ensure the most recent output is always visible. Sources: src/components/dashboard/KernelLogs.tsx:18-24
The visualizer maps severity levels to specific colors and icons:
- Error: Red text with a "✖" icon.
- Warning: Secondary color text with a "⚠" icon.
- Success: Primary green text with a "✔" icon.
- Info: Slate/default text with a "$" icon.
Sources: src/components/dashboard/KernelLogs.tsx:45-56
Log Display Flow
The following diagram illustrates how build events are transformed into UI elements.
AI Troubleshooting Analysis
The pipeline includes an AI-powered troubleshooting module. It converts the accumulated log state into a flat text string (logsText) and passes it to the aiBuildTroubleshootingAssistant flow. Sources: src/app/page.tsx:186, src/components/dashboard/AITroubleshooter.tsx:18-25
Analysis Input and Output
The AI assistant expects a specific schema for processing. Because the application is often exported as a static Android APK, the current implementation uses a mock assistant that simulates analysis delays and provides a standardized response format. Sources: src/ai/flows/ai-build-troubleshooting-assistant.ts:5-30
AI Assistant Output Schema
The processing result is categorized into three main fields to help users debug.
| Component | Type | Purpose |
|---|---|---|
summary | string | High-level overview of the build status or failure |
identifiedErrors | string[] | List of specific error codes or messages found in logs |
suggestedSolutions | string[] | Actionable steps to resolve the identified issues |
Sources: src/ai/flows/ai-build-troubleshooting-assistant.ts:21-25, src/components/dashboard/AITroubleshooter.tsx:64-90
Pipeline Summary
The Log Data Processing Pipeline effectively bridges the gap between raw terminal output and actionable developer insights. It utilizes a structured state management approach to handle real-time updates and integrates a diagnostic layer capable of parsing complex kernel build logs. This system is critical for maintaining GKI/KMI compatibility and ensuring successful integration of third-party patches like KernelSU and SUSFS. Sources: README.md:14-16, src/app/page.tsx:94-118