| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this commit[1], LoongArch now uses these Multiarch specs:
- Double float: loongarch64-linux-gnu
- Single float: loongarch64-linux-gnuf32
- Soft float: loongarch64-linux-gnusf
You can visit here[2] to view the full documentation.
[1]: https://github.com/loongson/LoongArch-Documentation/commit/55dbaadaaa90b5f5d08a74d96b866af42c8c3c82
[2]: https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html
|
|
|
|
|
| |
util.h is now about logarithms only, so we can rename it. Many files included
util.h for no apparent reason… Those includes are dropped.
|
|
|
|
|
|
|
| |
Some parts of our tree used 'Architecture' for storing architectures,
others used ints. Let's unify on the former.
Inspired by #22952's rework of the 'Virtualization' enum.
|
| |
|
| |
|
|
|
|
|
| |
For easier integration with the _GPT_ALL_ARCHES macro in a future
commit.
|
| |
|
|
|
|
| |
It's just too annoying to add new ones otherwise.
|
| |
|
|
|
|
|
|
|
|
|
| |
As suggested in https://github.com/systemd/systemd/pull/11484#issuecomment-775288617.
This does not touch anything exposed in src/systemd. Changing the defines there
would be a compatibility break.
Note that tests are broken after this commit. They will be fixed in the next one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These lines are generally out-of-date, incomplete and unnecessary. With
SPDX and git repository much more accurate and fine grained information
about licensing and authorship is available, hence let's drop the
per-file copyright notice. Of course, removing copyright lines of others
is problematic, hence this commit only removes my own lines and leaves
all others untouched. It might be nicer if sooner or later those could
go away too, making git the only and accurate source of authorship
information.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
|
|
|
|
|
|
|
|
|
|
| |
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
|
|
|
|
|
| |
This follows what the kernel is doing, c.f.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fd54ace4721fc5ce2bb5aef6318fcf17f421460.
|
|
|
|
|
| |
DesignWare ARC Processors are a family of 32-bit CPUs from Synopsys
used extensively in SoCs of different vendors.
|
|
|
|
|
|
|
| |
On SuperH, there are multiple sub-architectures defined with
different values for LIB_ARCH_TUPLE. The different sub-
architectures can be detected by checking whether __SH1__,
__SH2__, __SH3__, __SH4__, and so on are defined.
|
|
|
|
|
|
|
|
| |
On powerpc, there are two possible ABIs and hence values for
LIB_ARCH_TUPLE. The convential type with an FPU and the embedded
variant, called powerpcspe, which does not have a convential FPU
but a special Signal Processing Engine (SPE). The latter can be
detected by checking whether __NO_FPRS__ is defined.
|
|
|
|
|
|
|
| |
On x86_64, there are two possible ABIs and hence values for
LIB_ARCH_TUPLE. The convential 64-bit type and the 32-bit
variant, called x32. The latter can be detected by checking
whether __ILP32__ is defined.
|
|
|
|
|
|
|
| |
* Fix MIPS N64 and N32 LIB_ARCH_TUPLE
For mips, we have 3 major ABIs, they are N64, N32 and O32.
Both N32 and N64 defined __mips64__, and only N64 defined __LP64__.
|
|
|
|
|
| |
Fix build failure on the tilegx architecture.
https://bugs.debian.org/856306
|
|
|
|
|
|
| |
https://lists.freedesktop.org/archives/systemd-devel/2017-February/038286.html
Let's keep both the old and new for now, so systemd builds correctly in either
environment. Later on we should drop the old.
|
|
|
|
| |
Completely unstested. Fixes #4862.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RISC-V is an open source ISA in development since 2010 at UCB.
For more information, see https://riscv.org/
I am adding RISC-V support to Fedora:
https://fedoraproject.org/wiki/Architectures/RISC-V
There are three major variants of the architecture (32-, 64- and
128-bit). The 128-bit variant is a paper exercise, but the other
two really exist in silicon. RISC-V is always little endian.
On Linux, the default kernel uname(2) can return "riscv" for all
variants. However a patch was added recently which makes the kernel
return one of "riscv32" or "riscv64" (or in future "riscv128"). So
systemd should be prepared to handle any of "riscv", "riscv32" or
"riscv64" (in future, "riscv128" but that is not included in the
current patch). If the kernel returns "riscv" then you need to use
the pointer size in order to know the real variant.
The Fedora/RISC-V kernel only ever returns "riscv64" since we're
only doing Fedora for 64 bit at the moment, and we've patched the
kernel so it doesn't return "riscv".
As well as the major bitsize variants, there are also architecture
extensions. However I'm trying to ensure that uname(2) does *not*
return any other information about those in utsname.machine, so that
we don't end up with "riscv64abcde" nonsense. Instead those
extensions will be exposed in /proc/cpuinfo similar to how flags
work in x86.
|
| |
|
|
|
|
| |
Add nios2 architecture support. The nios2 is a softcore by Altera.
|
|
|
|
| |
This was only needed for bootchart, so it can go now.
|
| |
|
|
After all, it is pretty generic, has no external deps besides libc, and is very
similar to virt.[ch] which is also in basic/
|