Announcement

Collapse
No announcement yet.

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

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

  • #31
    Originally posted by pal666 View Post
    lolwut? android can't ship in one update both kernel and headers?
    lolwutwut? Nothing exists outside Android?

    Widen your dreams, brother! There is another world out there, where linux shines and developpers tend to be happy when you simplify their work, because they have to ship this damn code!

    (And besides that, you should read the discussion on LKML, because yes, the root of the problem is the massive number of different Android kernels out there).

    Comment


    • #32
      Originally posted by smitty3268 View Post

      Yeah, why isn't that the obvious solution here? I'm not sure i get why this was even proposed.
      Because it's not workable. Android is not one kernel. It's a myriad of vendor-patched kernels. While Google can do what it wants on the version it proposes, the vendors have to be more or less forced into doing the correct thing (most vendors are not intentionally ruining Google plans ; they also make genuine mistakes and interpretation errors). Having a /proc/kheaders.tgz (or whatever) would fix the issue once for all: you have to ship the module or you Android cannot be certified. Plus, /proc can easily be mounted in its own mount+pid namespace, allowing any app to get it without having to cope with strange access rights on an unknown part of the main fs.

      Now, for the memory: we're dealing with systems that have 2, 4, 8 or even more GB of memory. 3.3MB is not what I would call abhorrent in this uses case.

      Comment


      • #33
        The AMD GPU driver is bigger than the kernel headers....

        Comment


        • #34
          Originally posted by pal666 View Post
          lol, now you are trying to say that fuchsia will replace android but will still use linux kernel? it seems now you've redefined fuchsia from os to language bindings
          LOL, not going to feed you anymore, troll, if you can't be bothered to read my posts correctly.

          Comment


          • #35
            Originally posted by starshipeleven View Post
            By having some Android functionality depend from it.
            let it depend on separate headers then

            Comment


            • #36
              Originally posted by Emmanuel Deloget View Post
              There is another world out there, where linux shines and developpers tend to be happy when you simplify their work, because they have to ship this damn code!
              why do you can ship kernel modules, but can't ship kernel headers?
              Originally posted by Emmanuel Deloget View Post
              (And besides that, you should read the discussion on LKML, because yes, the root of the problem is the massive number of different Android kernels out there).
              how number of android kernels precludes shipment of headers outside of kernel modules?

              Comment


              • #37
                Originally posted by Vistaus View Post
                you can't be bothered to read my posts correctly.
                i take it you tried to say that fuchsia will replace both linux kernel AND something else (the stuff which makes android more than linux). this is even more ridiculous than replacing just kernel.

                Comment


                • #38
                  Originally posted by pal666 View Post
                  why do you can ship kernel modules, but can't ship kernel headers?
                  I can. The fact is that it's way simpler to ship a module which is, by essence (and due to the fact that it's compiled with vermagic support) tied to this very kernel than to verify that, along a tree containing multiple kernels tailored to different CPUs, I'm really shipping the correct bpf.h file.

                  Originally posted by pal666 View Post
                  how number of android kernels precludes shipment of headers outside of kernel modules?
                  You are really astonishing. The whole thing makes our work easier. Any other solution is not impossible per see. This one is easy, and it can be easily implemented by all vendors out there ; it's easy to make it automatic ; it's easy to use after that. That's the reason why I think it's good. That does not preclude any other easy solution to exist.

                  When it comes to this use case, your words show that you're a user - you're not even supposed to be confronted to this, so why do you even care? It's not that the whole linux code base will rot in hell because of this 50 lines change.


                  Comment


                  • #39
                    Originally posted by Emmanuel Deloget View Post
                    I can. The fact is that it's way simpler to ship a module which is, by essence (and due to the fact that it's compiled with vermagic support) tied to this very kernel than to verify that, along a tree containing multiple kernels tailored to different CPUs, I'm really shipping the correct bpf.h file.
                    kernel header is just as tied to this kernel. there is no difference. if you are shipping correct bpf.ko, you are shipping correct bpf.h
                    Originally posted by Emmanuel Deloget View Post
                    You are really astonishing. The whole thing makes our work easier.
                    it makes no difference to your work
                    Originally posted by Emmanuel Deloget View Post
                    Any other solution is not impossible per see.
                    well, i hope i wouldn't have to use devices designed by people too dumb to put header in versioned directory just like module
                    Originally posted by Emmanuel Deloget View Post
                    When it comes to this use case, your words show that you're a user - you're not even supposed to be confronted to this, so why do you even care? It's not that the whole linux code base will rot in hell because of this 50 lines change.
                    you can't see how to ship header and you can't see who is your opponent. actually i'm programmer and i've authored kernel modules

                    Comment


                    • #40
                      Originally posted by pal666 View Post
                      kernel header is just as tied to this kernel. there is no difference. if you are shipping correct bpf.ko, you are shipping correct bpf.h
                      Loading a versioned module either fails or succeed. If it fails then it means that the kernel version is incorrect.
                      How can I have a similar test with a header file? How do you make sure, once the file is on the platform, that it's the correct file for this kernel version?

                      Originally posted by pal666 View Post
                      it makes no difference to your work
                      Anything that makes my work simpler makes a difference. Instead of having a separate build step, the module is built with the other modules. Simpler.

                      Originally posted by pal666 View Post
                      well, i hope i wouldn't have to use devices designed by people too dumb to put header in versioned directory just like module
                      You do whatever you want.

                      Originally posted by pal666 View Post
                      you can't see how to ship header and you can't see who is your opponent. actually i'm programmer and i've authored kernel modules
                      Good for you That still does not make you a kernel integrator or a distribution "vendor"

                      For god's sake: what is the freaking cost of having a module instead of a few hundred header files? What makes you so afraid?

                      Comment

                      Working...
                      X