-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mips64el support #161158
mips64el support #161158
Changes from all commits
12371a5
3cf8318
5b63b25
8a1235f
e748e1f
998fd40
ed4fa55
6de935a
ff69b8c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -93,6 +93,26 @@ rec { | |
config = "mipsel-unknown-linux-gnu"; | ||
} // platforms.fuloong2f_n32; | ||
|
||
# MIPS ABI table transcribed from here: https://wiki.debian.org/Multiarch/Tuples | ||
|
||
# can execute on 32bit chip | ||
mips-linux-gnu = { config = "mips-linux-gnu"; } // platforms.gcc_mips32r2_o32; | ||
mipsel-linux-gnu = { config = "mipsel-linux-gnu"; } // platforms.gcc_mips32r2_o32; | ||
mipsisa32r6-linux-gnu = { config = "mipsisa32r6-linux-gnu"; } // platforms.gcc_mips32r6_o32; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This also does not evaluate. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See above. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As an aside, it would be really nice if nixpkgs had a template "here's what you need to fill in to add support for a new platform", all in one file. Right now it's scattered all over the place in Having everything needed to support each new platform in one place for each platform would make it obvious whether things like this are checked in because we were transcribing some table for the benefit of future platforms-to-be-added, or whether full platform support is intended. In the former case there would be missing entries (attrsets with a A nixpkgs "platform" is really just a gnu 5-tuple (cpumode, vendor, kernel, libc, abi). Everything else (kernel flags, compiler optimization flags, etc) are site-specific customizations which don't affect interoperatbility between different derivations. I would advise eliminating any distinction between "platform" and "gnu 5-tuple". Then, for a given product that can be bought (say, a Raspberry Pi), all you need to know is which kernel to use. Kernel configuration is much more complex than just a 5-tuple, and will vary among different devices which belong to the same 5-tuple. Any given kernel will support some set of one or more 5-tuples (for example, amd64 machines can run i386-linux-gnu userspaces as well as x86_64-linux-musl userspaces), and a nixpkgs kernel expression ought to be able to enumerate (or at least predicate) which 5-tuples it supports. Once you've picked your hardware and picked your kernel, you pick your platform from those which your chosen kernel supports, then you're done. |
||
mipsisa32r6el-linux-gnu = { config = "mipsisa32r6el-linux-gnu"; } // platforms.gcc_mips32r6_o32; | ||
|
||
# require 64bit chip (for more registers, 64-bit floating point, 64-bit "long long") but use 32bit pointers | ||
mips64-linux-gnuabin32 = { config = "mips64-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32; | ||
mips64el-linux-gnuabin32 = { config = "mips64el-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32; | ||
mipsisa64r6-linux-gnuabin32 = { config = "mipsisa64r6-linux-gnuabin32"; } // platforms.gcc_mips64r6_n32; | ||
mipsisa64r6el-linux-gnuabin32 = { config = "mipsisa64r6el-linux-gnuabin32"; } // platforms.gcc_mips64r6_n32; | ||
|
||
# 64bit pointers | ||
mips64-linux-gnuabi64 = { config = "mips64-linux-gnuabi64"; } // platforms.gcc_mips64r2_64; | ||
mips64el-linux-gnuabi64 = { config = "mips64el-linux-gnuabi64"; } // platforms.gcc_mips64r2_64; | ||
mipsisa64r6-linux-gnuabi64 = { config = "mipsisa64r6-linux-gnuabi64"; } // platforms.gcc_mips64r6_64; | ||
mipsisa64r6el-linux-gnuabi64 = { config = "mipsisa64r6el-linux-gnuabi64"; } // platforms.gcc_mips64r6_64; | ||
|
||
muslpi = raspberryPi // { | ||
config = "armv6l-unknown-linux-musleabihf"; | ||
}; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,10 @@ | ||
# Note: lib/systems/default.nix takes care of producing valid, | ||
# fully-formed "platform" values (e.g. hostPlatform, buildPlatform, | ||
# targetPlatform, etc) containing at least the minimal set of attrs | ||
# required (see types.parsedPlatform in lib/systems/parse.nix). This | ||
# file takes an already-valid platform and further elaborates it with | ||
# optional fields such as linux-kernel, gcc, etc. | ||
|
||
{ lib }: | ||
rec { | ||
pc = { | ||
|
@@ -482,6 +489,43 @@ rec { | |
}; | ||
}; | ||
|
||
# can execute on 32bit chip | ||
gcc_mips32r2_o32 = { gcc = { arch = "mips32r2"; abi = "o32"; }; }; | ||
gcc_mips32r6_o32 = { gcc = { arch = "mips32r6"; abi = "o32"; }; }; | ||
gcc_mips64r2_n32 = { gcc = { arch = "mips64r2"; abi = "n32"; }; }; | ||
gcc_mips64r6_n32 = { gcc = { arch = "mips64r6"; abi = "n32"; }; }; | ||
gcc_mips64r2_64 = { gcc = { arch = "mips64r2"; abi = "64"; }; }; | ||
gcc_mips64r6_64 = { gcc = { arch = "mips64r6"; abi = "64"; }; }; | ||
|
||
# based on: | ||
# https://www.mail-archive.com/[email protected]/msg05179.html | ||
# https://gmplib.org/~tege/qemu.html#mips64-debian | ||
mips64el-qemu-linux-gnuabi64 = (import ./examples).mips64el-linux-gnuabi64 // { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
linux-kernel = { | ||
name = "mips64el"; | ||
baseConfig = "64r2el_defconfig"; | ||
target = "vmlinuz"; | ||
autoModules = false; | ||
DTB = true; | ||
# for qemu 9p passthrough filesystem | ||
extraConfig = '' | ||
MIPS_MALTA y | ||
PAGE_SIZE_4KB y | ||
CPU_LITTLE_ENDIAN y | ||
CPU_MIPS64_R2 y | ||
64BIT y | ||
CPU_MIPS64_R2 y | ||
|
||
NET_9P y | ||
NET_9P_VIRTIO y | ||
9P_FS y | ||
9P_FS_POSIX_ACL y | ||
PCI y | ||
VIRTIO_PCI y | ||
''; | ||
}; | ||
}; | ||
|
||
## | ||
## Other | ||
## | ||
|
@@ -499,6 +543,9 @@ rec { | |
}; | ||
}; | ||
|
||
# This function takes a minimally-valid "platform" and returns an | ||
# attrset containing zero or more additional attrs which should be | ||
# included in the platform in order to further elaborate it. | ||
select = platform: | ||
# x86 | ||
/**/ if platform.isx86 then pc | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This this been tested at all? This does not even build stdenv: https://hercules-ci.com/github/nix-community/cross-toolchains.nix/jobs/76
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are not yet supported, nor are they expected to evaluate. From the commit message,
As the one-line comment at the top of the block you quoted says, it is just a transcription of the table which enumerates all the possible {cpumode,kernel,libc,abi} combinations, since mips has a lot of them -- probably more than any other architecture. I transcribed the table to (a) discourage future platform support from cooking up custom nonstandard platform names and (b) show people that no, there isn't an infinite neverending list of combinations; there is a limit to how many of these we will ever care about.
Right now only mips64el-linux-{gnu,musl}abi64 works 100% (after all my PRs get merged). Support for gnuabin32 is very close; as soon as
boost-context
adds support for it we will have that too.😝
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the point of having a tuple that cannot be tested in any way. This sounds like deadcode to me. It should have at least a comment stating that it cannot be used yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are approximately 182 licenses in
licenses.nix
, none of which can be "tested in an way". This is okay, because they aren't code; they are us teaching Nix about a list of things that exists outside of Nix, in the real world.The mips 5-tuple table is the same thing, but for chips instead of legal documents. Don't think of it as executable code.
Sorry to see that you got frustrated so quickly with trying to add a new platform to nixpkgs. I found the experience very frustrating too.
I have also found the nixpkgs process for merging complex, multi-commit changes (like the mips64el support) to be frustrating. Reviewers very sensibly ask that large and complex changes be broken up into multiple PRs, but GitHub totally fails to provide any kind of dependency tracking between bugs (kerneldev workflow handles this easily with the notion of a "patch series"). Since PRs that do not evaluate correctly tend to not attract any reviews, the person submitting a complex multi-PR changeset basically has to wait for each one to be merged before submitting the next. Technically you can submit them all at once, like I did, but there is no benefit to doing this when you have a long dependency chain: only the first PR in the chain will evaluate correctly; the rest will not evaluate (due to the earlier one not yet being merged), so those will fail CI and not be reviewed until the early one gets merged and then the submitter goes back and manually rebases all the later PRs. So really there is no benefit to submitting them all at once. The submitter has to manually submit them one at a time, waiting for each to merge before submitting the next.
To summarize: I think the nixpkgs-github process is optimized to attract "drive-by" one-liner patches from casual contributors (like my systemdSupport patches), at the cost of not being able to cope well with large/complex changes (like my mips64el patches) and refactorings (like cleaning up lib/systems/, which is... tangled) other than simple treewide search-and-replace. I'm sure that optimizing for casual contributions helped nixpkgs grow fast early on, but it doesn't seem to be a good way to limit the growth of "technical debt".
Anyways, because of the headaches of managing not-yet-fully-merged multi-PR submissions, I'm going to wait for all of my mips64el work (#161162, #163401, #161159, #164835, #161925, #161163) to get fully merged all the way to master, and bootstrap tarballs to be built, before I start working on any other mips tuples. When I do, the little-endian ones will be first; in order to test big-endian I'll need to set up another machine with a big-endian kernel.
PS, an orthogonal problem is that PRs that deal with changes to non-package nix files (like
lib/*
) don't have ameta.maintainer
who is obligated to review the PR, or at least give an idea of when they might get around to doing that. So they kinda just sit around, with the massively-overburdened "default code owners" (edolstra, alyssais, etc) assigned. I bet they get hundreds of review auto-requests per day, which is totally not scalable.