Announcement

Collapse
No announcement yet.

The Increasing Size Of The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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.

    Comment


    • #22
      Originally posted by Qaridarium
      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.

      Comment


      • #23
        Originally posted by jokeyrhyme View Post
        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

        Comment


        • #24
          Originally posted by chenxiaolong View Post
          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.

          Comment


          • #25
            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.

            Comment


            • #26
              Originally posted by YavkatA View Post
              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.

              Comment


              • #27
                Originally posted by siride View Post
                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

                Comment


                • #28
                  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.

                  Code:
                  [email protected]:~/packages/src/kernel/stable/linux-3.1$ du -sh
                  1.2G    .
                  [email protected]:~/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
                  
                  [email protected]:/lib/modules/3.1.0$ du -sh
                  14M    .

                  Comment


                  • #29
                    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?

                    Comment


                    • #30
                      Originally posted by Ex-Cyber View Post
                      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.

                      Comment

                      Working...
                      X