Re: Question about quantifying Linux kernel functional growth across releases

[Christian Loehle <christian.loehle@arm.com>]

On 9/3/26 06:13, 陈鑫 wrote:
> Hello,
> 
> I am analyzing how the Linux kernel evolves across releases, for
> example 4.19, 5.4, 5.10, 5.15, 6.1, and 6.6.
> 
> I am looking for a technically meaningful and reproducible way to
> quantify changes in the kernel's functional scope over time.
> 
> I understand that there is no well-defined concept of a "number of
> features" in the Linux kernel. One metric I am considering is the
> number of unique Kconfig symbols in each release, since Kconfig
> represents a broad range of configurable kernel capabilities,
> including subsystems, device drivers, architecture support,
> filesystems, networking, security features, and so on.
> 
> For example, I am considering collecting statistics such as:
> 
> * total number of unique Kconfig symbols in each release;
> * number of symbols added and removed between releases;
> * changes grouped by major areas such as drivers, networking,
> filesystems, security, and architecture.
> 
> I would appreciate the community's views on the following questions:
> 
> 1. Is the number of Kconfig symbols a reasonable proxy for comparing
> the functional scope of different kernel releases?
> 

My intuition would be no, many subsystems even try to reduce the number
of Kconfigs (with steady or increasing features), as long as cost is
justifiable.

> 2. What are the main limitations or pitfalls of using Kconfig symbols
> for this purpose?

It'll be vastly dominated by drivers?
Is this really part of 'functional scope'/features?

> 
> 3. Are there other quantitative metrics that kernel developers
> consider more meaningful for describing the growth or evolution of
> kernel capabilities?

Maybe syscalls? sysfs writable knobs?

> 
> 4. Are there existing tools, kernel.org statistics, or
> community-maintained datasets that track this kind of evolution across
> releases?

I'm not aware of a functional scope tracking.

> 
> My intention is not to claim an exact "feature count" for Linux. I am
> trying to identify a metric, or preferably a combination of metrics,
> that is technically defensible, reproducible, and suitable for
> comparing kernel evolution over time.
> 
> Any suggestions, references, or pointers to previous discussions would
> be greatly appreciated.
> 
> Thanks,
> Xin Chen
>