The Increasing Size Of The Linux Kernel

[Smorg]

Frankly I'm shocked that all those added drivers and capabilities only blew up the code by a little over double between 2.6 and 3.0. We're talking like numerous additional filesystems, network protocols, security modules, whole frameworks for supporting various hardware added.

[chenxiaolong]

i know how to slim the kernel down: delete all i386 code and i386 drivers and go for amd64 only.

The architecture specific code accounts for 116MB out of 498MB of code, with less than 8MB of code specific to the i*86 architecture.

Also, if the kernel developers go for amd64 only, then we'll be back in the internet-less world, since Linux won't support that MIPS processor in your modem and router anymore.

[DeepDayze]

I'd heard some earlier suggestions that legacy code (like ISA) be removed from the kernel going forward. I assume DRM1 code will eventually be removed (if there is any) as the focus seems to be on KMS, Gallium3D and DRM2 now. If they haven't already been removed the old SATA and Firewire drivers could probably be axed too.

Not all the ISA code as the mobo sensors use an ISA bus (yes every modern board still has ISA, even if no physical ISA slots).

Also any drivers for very old devices should be culled as such devices may no longer exist

[siride]

The architecture specific code accounts for 116MB out of 498MB of code, with less than 8MB of code specific to the i*86 architecture.

Also, if the kernel developers go for amd64 only, then we'll be back in the internet-less world, since Linux won't support that MIPS processor in your modem and router anymore.

MIPS isn't i386.

[YavkatA]

Given so many new devices released every year, this is unavoidable in the current design of the Linux Kernel. As it grows, any kind of development gets more and more difficult. I think the only solution for this problem is to turn to microkernels - have a core that is maintained by a set of core developers, and drivers that will run in userspace and be maintained by their respective vendors.

[siride]

Given so many new devices released every year, this is unavoidable in the current design of the Linux Kernel. As it grows, any kind of development gets more and more difficult. I think the only solution for this problem is to turn to microkernels - have a core that is maintained by a set of core developers, and drivers that will run in userspace and be maintained by their respective vendors.

You're assuming that there's actually a problem. If most of the new code is for device drivers, almost none of which have to be included in any given kernel, there isn't really an issue. Perhaps the tarball could be split into a core and several driver packages, so that the downloads don't take so long.

[DeepDayze]

You're assuming that there's actually a problem. If most of the new code is for device drivers, almost none of which have to be included in any given kernel, there isn't really an issue. Perhaps the tarball could be split into a core and several driver packages, so that the downloads don't take so long.

That could be the best way to go at some point...splitting out the drivers into their own package from the kernel base package

[amphigory]

This article is not really newsworthy. It would be more interesting if he showed architecture specific numbers and object code sizes. This is what I see with 3.1. Source tree 1.2G uncompressed (with built object files). My resulting kernel is 16M. gzip'd it is 3.3M. There is 14M in /lib/modules for this kernel with my build.

eherr@quark:~/packages/src/kernel/stable/linux-3.1$ du -sh
1.2G    .
eherr@quark:~/packages/src/kernel/stable/linux-3.1$ du -sh *
150M    arch
2.2M    block
20K    COPYING
96K    CREDITS
7.0M    crypto
19M    Documentation
307M    drivers
7.8M    firmware
62M    fs
24M    include
436K    init
804K    ipc
4.0K    Kbuild
4.0K    Kconfig
13M    kernel
5.3M    lib
200K    MAINTAINERS
56K    Makefile
5.6M    mm
4.0K    modules.builtin
16K    modules.order
360K    Module.symvers
55M    net
20K    README
4.0K    REPORTING-BUGS
156K    samples
3.5M    scripts
2.7M    security
35M    sound
1.9M    System.map
3.2M    tools
48K    usr
172K    virt
9.5M    vmlinux
16M    vmlinux.o

eherr@quark:/lib/modules/3.1.0$ du -sh
14M    .

[Ex-Cyber]

I don't understand the point of merely splitting the tarball. If you can't mix and match the "core" and "driver" parts (which you generally can't because Linux deliberately lacks stable kernel driver APIs), what good does it do to download them separately?

[siride]

I don't understand the point of merely splitting the tarball. If you can't mix and match the "core" and "driver" parts (which you generally can't because Linux deliberately lacks stable kernel driver APIs), what good does it do to download them separately?

I didn't explain it well enough. You'd have a core tarball that everyone needs, and then tarballs for individual drivers, or driver sets, that you could download as needed for your machine or architecture. It would be not unlike what binary distros do already with separate RPMs for modules.