-
Notifications
You must be signed in to change notification settings - Fork 109
Open
Description
- by running
init
directly, we may increase churn and certain inconsistencies in the source (see below) - we could initialize modules by having something like a
load_module
function that takes a name and a "function pointer" for "loading" and "unloading"
pros:
- we would avoid inconsistencies in where the conditions for the initialization of a module take place (refactor(fs): move uhyve check outside of init #1970)
- we could give modules a "name" and modify the macros used so that logs/kernel messages use said name, achieving a more "linux-like dmesg"-type of structure (style: improve user-facing kernel messages #1974)
- i.e. custom macros, similarly to
pr_debug
orpr_info
in the linux kernel
- i.e. custom macros, similarly to
- we could standardize "loading" and "unloading" modules similarly to the linux kernel
- an "enforced structure" wouldn't necessarily compromise flexibility, as we already do things like this anyway.
Metadata
Metadata
Assignees
Labels
No labels