Announcement

Collapse
No announcement yet.

Linux Headers May Soon Be Available In-Kernel Via /proc

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

  • Linux Headers May Soon Be Available In-Kernel Via /proc

    Phoronix: Linux Headers May Soon Be Available In-Kernel Via /proc

    In making it easier to manage and access the Linux kernel headers for a particular kernel build, Google engineers working on Android are proposing an in-kernel solution for mainline where a compressed archive of a given kernel's headers could be accessible via /proc...

    http://www.phoronix.com/scan.php?pag...l-Headers-Proc

  • #2
    I think it's ok (but rather stupid feature). It should not be used in moderately standard builds.
    Interfaces should be stable. Otherwise they belong in staging or somewhere else.
    Kernel headers promote the known feature set entry point for userspace.
    It's not like they need to be bleeding edge unless you explicitly want a shiny new feature from your latest and greatest kernel.

    I tend to build my kernels from the latest stable but keep the header entry point for userspace from the latest long lived maintenance series.
    This allows for forward AND backwards compatibility (from a future point back and up to the header point).

    This request is because a small subset of developers are fiddling with some remote part and can't manage to keep track of interface changes.
    I've seen people parse config.gz to check for features instead of asking the running kernel or having a proper interface.

    Developers only methinks.

    Comment


    • #3
      Reading the thread, I really dont think this is a good idea - packing an archive in a module, that lies in your rootfs. means the only thing this saves is finding out where a file is located in your rootfs.
      I would see the gain if you could build the loadable modules itselfs into the kernel and mount it into the rootfs. That way the rootfs (and initramfs) is independend of the kernelversion, and does noot need to be touched on updates.

      Comment


      • #4
        Plan 9 from Bell Labs, anyone?

        Comment


        • #5
          Wouldn't this only ever be useful for Android where each device/variant needs a fork of the kernel.

          Comment


          • #6
            I don't really like this thing.

            First, it doesn't either add any new kernel feature or pushes for any performance improvement. The "feature" would benefit compilations, not the runtime.

            Second, why hosting (part of) the kernel source code into the kernel itself when we already have the usual /usr/src/linux tree? Proper versioning? C'mon!

            Third, you are hosting static data inside the kernel that can be, but not necessarily are, used during some package compilations. Most of the kernels all around the world aren't compiling. Even as a loadable module, a simple access to the source tree would trigger a module pull for that stuff.

            Nope, if there was a vote, I's say "nay".

            Comment


            • #7
              I think this is a good feature for android if google forces this as a requirement for Android branding and logo.

              Comment


              • #8
                Originally posted by FastCode View Post
                I think this is a good feature for android if google forces this as a requirement for Android branding and logo.
                It'd be useful is you compile certain source packages ... under Android itself. Really unlikely in my opinion ...

                Comment


                • #9
                  So this is why new Android devices come with 12 GB of RAM? They store files in RAM?

                  Comment


                  • #10
                    Originally posted by Uqbar View Post
                    I don't really like this thing.

                    First, it doesn't either add any new kernel feature or pushes for any performance improvement. The "feature" would benefit compilations, not the runtime.
                    Same goes for /proc/config.gz, yet it's here.

                    I definitely see the point. A typical distro won't need it - it already has a powerful packaging system and a kernel-header package that matches the kernel itself. But embedded devices are a very different beast, and given the possibilities we have now (64 bits, GB or RAM) a 4MB module or built-in does not seems a very large price to pay in exchange of being sure that these are the kernel header for that kernel.

                    Originally posted by Uqbar View Post
                    Second, why hosting (part of) the kernel source code into the kernel itself when we already have the usual /usr/src/linux tree? Proper versioning? C'mon!
                    Like I said, not every Linux system is based upon a large, well known linux distribution. If the kernel includes are integrated to the kernel image, it's one more thing I don't have to worry about.

                    [QUOTE=Uqbar;n1075746]
                    Third, you are hosting static data inside the kernel that can be, but not necessarily are, used during some package compilations. Most of the kernels all around the world aren't compiling. Even as a loadable module, a simple access to the source tree would trigger a module pull for that stuff.
                    [QUOTE]

                    Well, I don't always use all the features of the kernel each time I use Linux

                    Comment

                    Working...
                    X