ldls: what 110 modules ask for at init, in order of how many ask
Counting stub calls turned out to be the wrong metric -- one module walking an
rbtree called rb_first sixty-four times and told us nothing. Counting how many
*modules* need a symbol is the useful one:
__kmem_cache_create_args 25
crypto_register_template 11
_printk 10
crypto_register_alg 10
__register_nls 9
...
Forty-four distinct symbols carry all 110 modules through init_module. Small
enough to be a plan rather than an estimate, and not a number anyone could
have guessed: the slab allocator at the top and a long tail of registration
calls that mostly want to record a pointer and return zero.
It says nothing about probe(), which is where the real surface is and which
the kernel rather than the module is supposed to call. That is L2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
This commit is contained in:
parent
7a7c7611e0
commit
7dd2b03e36
1 changed files with 26 additions and 0 deletions
|
|
@ -345,6 +345,32 @@ The 22 are not failures of the loader; they are drivers that needed an
|
|||
allocation to come back non-null. The 29 without an entry point are mostly
|
||||
library modules that exist to be depended on.
|
||||
|
||||
### And what it says about the work queue
|
||||
|
||||
Counting *calls* is the wrong metric — one module walking an rbtree called
|
||||
`rb_first` sixty-four times and told us nothing. Counting **how many modules
|
||||
need a symbol** is the useful one, and over 110 modules it comes to this:
|
||||
|
||||
| symbol | modules |
|
||||
|---|---|
|
||||
| `__kmem_cache_create_args` | 25 |
|
||||
| `crypto_register_template` | 11 |
|
||||
| `_printk` | 10 |
|
||||
| `crypto_register_alg` | 10 |
|
||||
| `__register_nls` | 9 |
|
||||
| `crypto_register_shash` | 4 |
|
||||
| `af_alg_register_type` | 4 |
|
||||
| `register_filesystem`, `misc_register`, … | 2 each |
|
||||
|
||||
**Forty-four distinct symbols would carry every one of those 110 modules
|
||||
through `init_module`.** That is a small enough number to be a plan rather than
|
||||
an estimate, and it is not a number anybody could have guessed — the slab
|
||||
allocator at the top, and a long tail of registration calls that mostly want to
|
||||
record a pointer and return zero.
|
||||
|
||||
It says nothing about `probe()`, which is where the real surface is and which
|
||||
the kernel, not the module, is supposed to call. Reaching that is L2.
|
||||
|
||||
---
|
||||
|
||||
## What it will not do
|
||||
|
|
|
|||
Loading…
Reference in a new issue