The Increasing Size Of The Linux Kernel

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

[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

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

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

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

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

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

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

[chenxiaolong]

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.

But BusyBox requires the Linux kernel to run right?

From the busybox about page:

To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.

From the serial console on my router, I see that the kernel boots and then BusyBox loads later in the boot sequence. I don't quite understand how the kernel can boot if it doesn't support MIPS.