The Increasing Size Of The Linux Kernel

[chenxiaolong]

MIPS isn't i386. and also you don't count the drivers from old i386 only hardware.

be sure its more than 8mb.

i don't call for deleting all 32bit stuff only the intel 32bit stuff.

Got it Thanks for clarifying.

[siride]

I'm not sure how you'd get useful granularity with multiple driver tarballs. It seems like no matter how you split it, you'd run into the problem of "80% of the users use 20% of the code, but it's never the same 20%".

Any given user, however, would only need to use a small part and thus would only need to download a small part. That's for the hobbiests who actually need to download the kernel source, and distros to build their own binaries. For most end-users, this is entirely a non-issue.

[yogi_berra]

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.

Linux doesn't have to support MIPS, busybox has to. There is no reason, beyond sheer laziness or incompetence, that the busybox people can't role their own code for MIPS.

[leeenux]

Ah, the joy of statistics.

I don't care if the sources hit 1GB, to be quite honest. I'll take the increase in size to mean that they've been busy fixing the various shortcomings the kernel has had over the years, and adding support for even more oddball architectures I'll never use.

The size of a compiled and packaged kernel still tends to be between 1MB and 100MB depending on what you've included. Come and alarm me when a compiled kernel hits 100GB and I no longer have the hard drive space to install it.

[Ex-Cyber]

I'm not sure how you'd get useful granularity with multiple driver tarballs. It seems like no matter how you split it, you'd run into the problem of "80% of the users use 20% of the code, but it's never the same 20%".

[amphigory]

It would be a pain in the ass having separate tarballs. No thanks. I well remember the days of building separate modules (Atheros (madwifi) or Prism54, etc) and do not miss them. Having the kernel and drivers in one tree makes things much easier.

[DeepDayze]

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.

Precisely what is meant

[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.

[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?

[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    .