Re: Question about quantifying Linux kernel functional growth across releases

[陈鑫]

Hello,

Thank you for the helpful comments.

Your point that Kconfig counts may be dominated by drivers, and that
some subsystems reduce configuration options while still adding
functionality, makes sense. This suggests that Kconfig symbols may be
more useful for measuring configuration surface than functional scope
itself.

My broader goal is to build a reproducible way to compare kernel
capabilities across releases, and eventually answer questions such as:

* how the functional scope of the kernel changes over time;
* how much of that scope is security-related;
* what subset of kernel capabilities is relevant to or enabled in Android.

Would it make sense to treat kernel evolution as several measurable
dimensions rather than a single "feature count", for example:

* userspace-visible interfaces: syscalls, sysfs/procfs, ioctls, netlink;
* subsystem capabilities: filesystems, networking, security,
virtualization, etc.;
* hardware support: drivers and architectures;
* configuration surface: Kconfig symbols.

For security, is there an established way to define or classify kernel
security capabilities beyond simply counting CONFIG_SECURITY_*
symbols?

For Android, would comparing an Android/GKI kernel configuration with
the upstream kernel configuration space be a reasonable starting point
for estimating the enabled capability subset, while acknowledging that
configuration does not map one-to-one to actual functionality?

If you were doing this kind of historical comparison, what two or
three metrics would you consider the least misleading?

Thanks again for your guidance.

Best regards,
Xin Chen

Christian Loehle <christian.loehle@xxxxxxx> 于2026年9月3日周四 16:05写道：
>
> 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
> >
>


-- 

陈鑫

Tel：18600991213
QQ：177854940