Kernel architecture vs OS architecture

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












What is the difference between the kernel architecture and the OS architecture? Which of these is relevant when trying to figure out which architecture to compile binaries for?



From what I have read, it is possible to install a 64 bit kernel despite using a 32 bit OS in some distributions.



What does uname -i print, the kernel architecture or the OS architecture? What about dpkg --print-architecture and arch?







share|improve this question
















  • 1




    In the context of compilers and packages, "architecture" refers to the instruction set architecture (ISA) of the processor on which they are intended to run. I have no idea what an "operating system architecture" may be. For example, i386 (or i686) refers to 32-bit x86-compatible processors, amd64 refers to the 64-bit x86 instruction set, and armel means little-endian ARM.
    – AlexP
    Nov 18 '17 at 16:24











  • What he meant is that the kernel can be 64bits and run a whole 32bits userland (and for the OP yes it's possible to run that, usually upgrading a 32bits install. look at dpkg --add-architecture amd64)
    – A.B
    Nov 18 '17 at 16:28















up vote
1
down vote

favorite












What is the difference between the kernel architecture and the OS architecture? Which of these is relevant when trying to figure out which architecture to compile binaries for?



From what I have read, it is possible to install a 64 bit kernel despite using a 32 bit OS in some distributions.



What does uname -i print, the kernel architecture or the OS architecture? What about dpkg --print-architecture and arch?







share|improve this question
















  • 1




    In the context of compilers and packages, "architecture" refers to the instruction set architecture (ISA) of the processor on which they are intended to run. I have no idea what an "operating system architecture" may be. For example, i386 (or i686) refers to 32-bit x86-compatible processors, amd64 refers to the 64-bit x86 instruction set, and armel means little-endian ARM.
    – AlexP
    Nov 18 '17 at 16:24











  • What he meant is that the kernel can be 64bits and run a whole 32bits userland (and for the OP yes it's possible to run that, usually upgrading a 32bits install. look at dpkg --add-architecture amd64)
    – A.B
    Nov 18 '17 at 16:28













up vote
1
down vote

favorite









up vote
1
down vote

favorite











What is the difference between the kernel architecture and the OS architecture? Which of these is relevant when trying to figure out which architecture to compile binaries for?



From what I have read, it is possible to install a 64 bit kernel despite using a 32 bit OS in some distributions.



What does uname -i print, the kernel architecture or the OS architecture? What about dpkg --print-architecture and arch?







share|improve this question












What is the difference between the kernel architecture and the OS architecture? Which of these is relevant when trying to figure out which architecture to compile binaries for?



From what I have read, it is possible to install a 64 bit kernel despite using a 32 bit OS in some distributions.



What does uname -i print, the kernel architecture or the OS architecture? What about dpkg --print-architecture and arch?









share|improve this question











share|improve this question




share|improve this question










asked Nov 18 '17 at 14:20









just.kidding

1142




1142







  • 1




    In the context of compilers and packages, "architecture" refers to the instruction set architecture (ISA) of the processor on which they are intended to run. I have no idea what an "operating system architecture" may be. For example, i386 (or i686) refers to 32-bit x86-compatible processors, amd64 refers to the 64-bit x86 instruction set, and armel means little-endian ARM.
    – AlexP
    Nov 18 '17 at 16:24











  • What he meant is that the kernel can be 64bits and run a whole 32bits userland (and for the OP yes it's possible to run that, usually upgrading a 32bits install. look at dpkg --add-architecture amd64)
    – A.B
    Nov 18 '17 at 16:28













  • 1




    In the context of compilers and packages, "architecture" refers to the instruction set architecture (ISA) of the processor on which they are intended to run. I have no idea what an "operating system architecture" may be. For example, i386 (or i686) refers to 32-bit x86-compatible processors, amd64 refers to the 64-bit x86 instruction set, and armel means little-endian ARM.
    – AlexP
    Nov 18 '17 at 16:24











  • What he meant is that the kernel can be 64bits and run a whole 32bits userland (and for the OP yes it's possible to run that, usually upgrading a 32bits install. look at dpkg --add-architecture amd64)
    – A.B
    Nov 18 '17 at 16:28








1




1




In the context of compilers and packages, "architecture" refers to the instruction set architecture (ISA) of the processor on which they are intended to run. I have no idea what an "operating system architecture" may be. For example, i386 (or i686) refers to 32-bit x86-compatible processors, amd64 refers to the 64-bit x86 instruction set, and armel means little-endian ARM.
– AlexP
Nov 18 '17 at 16:24





In the context of compilers and packages, "architecture" refers to the instruction set architecture (ISA) of the processor on which they are intended to run. I have no idea what an "operating system architecture" may be. For example, i386 (or i686) refers to 32-bit x86-compatible processors, amd64 refers to the 64-bit x86 instruction set, and armel means little-endian ARM.
– AlexP
Nov 18 '17 at 16:24













What he meant is that the kernel can be 64bits and run a whole 32bits userland (and for the OP yes it's possible to run that, usually upgrading a 32bits install. look at dpkg --add-architecture amd64)
– A.B
Nov 18 '17 at 16:28





What he meant is that the kernel can be 64bits and run a whole 32bits userland (and for the OP yes it's possible to run that, usually upgrading a 32bits install. look at dpkg --add-architecture amd64)
– A.B
Nov 18 '17 at 16:28











1 Answer
1






active

oldest

votes

















up vote
1
down vote













The kernel architecture is the kernel’s “preferred” architecture; it’s the architecture given by uname -m and arch (which are equivalent). For example, on a 64-bit kernel running on a 64-bit x86-compatible CPU, that will be x86_64.



On some platforms, the kernel can run binaries for multiple architectures; for example, a 64-bit x86 kernel can also run 32-bit binaries (with two ABIs, the “old” i386/i686 ABI, and x32). It supports this by instructing the CPU to run in 32-bit mode when running such binaries, and providing translation between 32-bit system calls and its native 64-bit system calls. With the addition of user-land emulation via QEMU, the kernel can also run binaries for any architecture supported by QEMU: for example, armhf on a 64-bit Intel CPU. In addition to the binaries themselves, and whatever translation layer is necessary, you’ll also need the appropriate libraries, in the same architecture as the binary; this is what multi-arch helps with, and before multi-arch, the /lib32//lib64 division of labour. (And if you think dealing with two or three ABIs is a lot, take a look at MIPS systems...)



In this context, “operating system architecture” could mean a number of things: it could be the architecture used when installing the system, or the architecture used by the majority of binaries in the system, etc. On Debian derivatives, it’s the architecture of the installed dpkg package, as given by dpkg --print-architecture.



When you’re building a binary, the easiest architecture to target is your compiler’s default target architecture, assuming you’ve got the appropriate libraries too. Usually, this will be the operating system architecture, whatever that means. The kernel architecture isn’t particularly significant here. On Debian derivatives, the expansion of multi-arch to cover cross-compilation means that it’s getting easier to build binaries for any supported Debian architecture, on any Debian system; but that’s a fairly specific use-case and still requires a reasonable level of familiarity with cross-compilation constraints. So stick with the default architecture...



uname -i prints a variant of the kernel architecture, when it prints anything; uname -p -i are unknown will tell you more about that.






share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405437%2fkernel-architecture-vs-os-architecture%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    1
    down vote













    The kernel architecture is the kernel’s “preferred” architecture; it’s the architecture given by uname -m and arch (which are equivalent). For example, on a 64-bit kernel running on a 64-bit x86-compatible CPU, that will be x86_64.



    On some platforms, the kernel can run binaries for multiple architectures; for example, a 64-bit x86 kernel can also run 32-bit binaries (with two ABIs, the “old” i386/i686 ABI, and x32). It supports this by instructing the CPU to run in 32-bit mode when running such binaries, and providing translation between 32-bit system calls and its native 64-bit system calls. With the addition of user-land emulation via QEMU, the kernel can also run binaries for any architecture supported by QEMU: for example, armhf on a 64-bit Intel CPU. In addition to the binaries themselves, and whatever translation layer is necessary, you’ll also need the appropriate libraries, in the same architecture as the binary; this is what multi-arch helps with, and before multi-arch, the /lib32//lib64 division of labour. (And if you think dealing with two or three ABIs is a lot, take a look at MIPS systems...)



    In this context, “operating system architecture” could mean a number of things: it could be the architecture used when installing the system, or the architecture used by the majority of binaries in the system, etc. On Debian derivatives, it’s the architecture of the installed dpkg package, as given by dpkg --print-architecture.



    When you’re building a binary, the easiest architecture to target is your compiler’s default target architecture, assuming you’ve got the appropriate libraries too. Usually, this will be the operating system architecture, whatever that means. The kernel architecture isn’t particularly significant here. On Debian derivatives, the expansion of multi-arch to cover cross-compilation means that it’s getting easier to build binaries for any supported Debian architecture, on any Debian system; but that’s a fairly specific use-case and still requires a reasonable level of familiarity with cross-compilation constraints. So stick with the default architecture...



    uname -i prints a variant of the kernel architecture, when it prints anything; uname -p -i are unknown will tell you more about that.






    share|improve this answer
























      up vote
      1
      down vote













      The kernel architecture is the kernel’s “preferred” architecture; it’s the architecture given by uname -m and arch (which are equivalent). For example, on a 64-bit kernel running on a 64-bit x86-compatible CPU, that will be x86_64.



      On some platforms, the kernel can run binaries for multiple architectures; for example, a 64-bit x86 kernel can also run 32-bit binaries (with two ABIs, the “old” i386/i686 ABI, and x32). It supports this by instructing the CPU to run in 32-bit mode when running such binaries, and providing translation between 32-bit system calls and its native 64-bit system calls. With the addition of user-land emulation via QEMU, the kernel can also run binaries for any architecture supported by QEMU: for example, armhf on a 64-bit Intel CPU. In addition to the binaries themselves, and whatever translation layer is necessary, you’ll also need the appropriate libraries, in the same architecture as the binary; this is what multi-arch helps with, and before multi-arch, the /lib32//lib64 division of labour. (And if you think dealing with two or three ABIs is a lot, take a look at MIPS systems...)



      In this context, “operating system architecture” could mean a number of things: it could be the architecture used when installing the system, or the architecture used by the majority of binaries in the system, etc. On Debian derivatives, it’s the architecture of the installed dpkg package, as given by dpkg --print-architecture.



      When you’re building a binary, the easiest architecture to target is your compiler’s default target architecture, assuming you’ve got the appropriate libraries too. Usually, this will be the operating system architecture, whatever that means. The kernel architecture isn’t particularly significant here. On Debian derivatives, the expansion of multi-arch to cover cross-compilation means that it’s getting easier to build binaries for any supported Debian architecture, on any Debian system; but that’s a fairly specific use-case and still requires a reasonable level of familiarity with cross-compilation constraints. So stick with the default architecture...



      uname -i prints a variant of the kernel architecture, when it prints anything; uname -p -i are unknown will tell you more about that.






      share|improve this answer






















        up vote
        1
        down vote










        up vote
        1
        down vote









        The kernel architecture is the kernel’s “preferred” architecture; it’s the architecture given by uname -m and arch (which are equivalent). For example, on a 64-bit kernel running on a 64-bit x86-compatible CPU, that will be x86_64.



        On some platforms, the kernel can run binaries for multiple architectures; for example, a 64-bit x86 kernel can also run 32-bit binaries (with two ABIs, the “old” i386/i686 ABI, and x32). It supports this by instructing the CPU to run in 32-bit mode when running such binaries, and providing translation between 32-bit system calls and its native 64-bit system calls. With the addition of user-land emulation via QEMU, the kernel can also run binaries for any architecture supported by QEMU: for example, armhf on a 64-bit Intel CPU. In addition to the binaries themselves, and whatever translation layer is necessary, you’ll also need the appropriate libraries, in the same architecture as the binary; this is what multi-arch helps with, and before multi-arch, the /lib32//lib64 division of labour. (And if you think dealing with two or three ABIs is a lot, take a look at MIPS systems...)



        In this context, “operating system architecture” could mean a number of things: it could be the architecture used when installing the system, or the architecture used by the majority of binaries in the system, etc. On Debian derivatives, it’s the architecture of the installed dpkg package, as given by dpkg --print-architecture.



        When you’re building a binary, the easiest architecture to target is your compiler’s default target architecture, assuming you’ve got the appropriate libraries too. Usually, this will be the operating system architecture, whatever that means. The kernel architecture isn’t particularly significant here. On Debian derivatives, the expansion of multi-arch to cover cross-compilation means that it’s getting easier to build binaries for any supported Debian architecture, on any Debian system; but that’s a fairly specific use-case and still requires a reasonable level of familiarity with cross-compilation constraints. So stick with the default architecture...



        uname -i prints a variant of the kernel architecture, when it prints anything; uname -p -i are unknown will tell you more about that.






        share|improve this answer












        The kernel architecture is the kernel’s “preferred” architecture; it’s the architecture given by uname -m and arch (which are equivalent). For example, on a 64-bit kernel running on a 64-bit x86-compatible CPU, that will be x86_64.



        On some platforms, the kernel can run binaries for multiple architectures; for example, a 64-bit x86 kernel can also run 32-bit binaries (with two ABIs, the “old” i386/i686 ABI, and x32). It supports this by instructing the CPU to run in 32-bit mode when running such binaries, and providing translation between 32-bit system calls and its native 64-bit system calls. With the addition of user-land emulation via QEMU, the kernel can also run binaries for any architecture supported by QEMU: for example, armhf on a 64-bit Intel CPU. In addition to the binaries themselves, and whatever translation layer is necessary, you’ll also need the appropriate libraries, in the same architecture as the binary; this is what multi-arch helps with, and before multi-arch, the /lib32//lib64 division of labour. (And if you think dealing with two or three ABIs is a lot, take a look at MIPS systems...)



        In this context, “operating system architecture” could mean a number of things: it could be the architecture used when installing the system, or the architecture used by the majority of binaries in the system, etc. On Debian derivatives, it’s the architecture of the installed dpkg package, as given by dpkg --print-architecture.



        When you’re building a binary, the easiest architecture to target is your compiler’s default target architecture, assuming you’ve got the appropriate libraries too. Usually, this will be the operating system architecture, whatever that means. The kernel architecture isn’t particularly significant here. On Debian derivatives, the expansion of multi-arch to cover cross-compilation means that it’s getting easier to build binaries for any supported Debian architecture, on any Debian system; but that’s a fairly specific use-case and still requires a reasonable level of familiarity with cross-compilation constraints. So stick with the default architecture...



        uname -i prints a variant of the kernel architecture, when it prints anything; uname -p -i are unknown will tell you more about that.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 18 '17 at 19:17









        Stephen Kitt

        143k22312377




        143k22312377



























             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405437%2fkernel-architecture-vs-os-architecture%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay