Bruce Ashfield f0436b3fde linux-yocto/6.16: cfg: x86 BIGSMP removal
Integrating the following commit(s) to linux-yocto/.:

1/1 [
    Author: Bruce Ashfield
    Email: bruce.ashfield@gmail.com
    Subject: x86: drop CONFIG_BIG_SMP
    Date: Tue, 9 Sep 2025 16:07:38 -0400

    commit 0abf508675c0dbbca6a387842f90db60756c4af5
    Author: Arnd Bergmann <arnd@arndb.de>
    Date:   Wed Feb 26 22:37:06 2025 +0100

        x86/smp: Drop 32-bit "bigsmp" machine support

        The x86-32 kernel used to support multiple platforms with more than eight
        logical CPUs, from the 1999-2003 timeframe: Sequent NUMA-Q, IBM Summit,
        Unisys ES7000 and HP F8. Support for all except the latter was dropped
        back in 2014, leaving only the F8 based DL740 and DL760 G2 machines in
        this catery, with up to eight single-core Socket-603 Xeon-MP processors
        with hyperthreading.

        Like the already removed machines, the HP F8 servers at the time cost
        upwards of $100k in typical configurations, but were quickly obsoleted
        by their 64-bit Socket-604 cousins and the AMD Opteron.

        Earlier servers with up to 8 Pentium Pro or Xeon processors remain
        fully supported as they had no hyperthreading. Similarly, the more
        common 4-socket Xeon-MP machines with hyperthreading using Intel
        or ServerWorks chipsets continue to work without this, and all the
        multi-core Xeon processors also run 64-bit kernels.

        While the "bigsmp" support can also be used to run on later 64-bit
        machines (including VM guests), it seems best to discourage that
        and get any remaining users to update their kernels to 64-bit builds
        on these. As a side-effect of this, there is also no more need to
        support NUMA configurations on 32-bit x86, as all true 32-bit
        NUMA platforms are already gone.

        Signed-off-by: Arnd Bergmann <arnd@arndb.de>
        Signed-off-by: Ingo Molnar <mingo@kernel.org>
        Cc: Linus Torvalds <torvalds@linux-foundation.org>
        Link: https://lore.kernel.org/r/20250226213714.4040853-3-arnd@kernel.org

    Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]

(From OE-Core rev: 71ab7d4524f9325862d3d6eefba33caec340615d)

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2025-09-11 11:31:56 +01:00
2024-02-19 11:34:33 +00:00
2021-07-19 18:07:21 +01:00

Poky

Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.

Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.

As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.

The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/

OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.

Contribution Guidelines

Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/ for full details on how to submit changes.

Where to Send Patches

As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:

OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):

BitBake (files in bitbake/):

Documentation (files in documentation/):

meta-yocto (files in meta-poky/, meta-yocto-bsp/):

If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.

CII Best Practices

Description
No description provided
Readme 252 MiB