- User Since
- Jul 4 2018, 7:23 PM (133 w, 5 d)
Manually pasted reduced-context diff to work around Phabricator's UTF-8-centric views
Hmph. Phabricator does not support ISO-8859-1 (their docs say so explicitly) so it balks on these files and treats them as binary. That's going to be fun. Anyway, here's the diff:
Rebase against shiny new repo
Sun, Jan 24
Sat, Jan 23
Fri, Jan 22
"freezes when building failures on macOS" in the commit message needs fixing
Thu, Jan 21
Rebase and address review comments
Don't know if I'm supposed to be able to push with a Reviewed by: + Approved by: debdrup, or if something just hates me, but I get "FATAL: VREF/APPROVERS-CHECK/doc: helper program exit status 65280", so could you please commit this for me?
Fix unintended whitespace diff
The documentation for these says "When set to a nonempty string", and the GNU world does the same (e.g. see LD_TRACE_LOADED_OBJECTS=1 /bin/echo on a GNU/Linux system), so the strcmp shouldn't be added.
@gnn You're currently a blocking reviewer on this
Wed, Jan 20
Tue, Jan 19
Mon, Jan 18
So one question is: how far makes sense to take this? Should rtld always read the ABI-specific libmap+hints and search in lib32/lib64? Only handling the ABI-specific environment variables is inconsistent.
Sat, Jan 16
Thu, Jan 14
Tue, Jan 12
Rebasing this on top of D28073 would help to reduce the diff (provided you're still happy with the concept, but if so it'd be good to land the cleanup first IMO before all the new code comes in).
Mon, Jan 11
Hm, my instinct would be to make it include GENERIC-MMCCAM instead and then turn of debugging, especially given the name.
Sun, Jan 10
Ok, so *without* this patch I see a fatal page fault for a small integer address, but *with* this patch I see it attempting (but failing due to the buggy dtrace_fuword64 implementation) to read from a sensible address:
Sat, Jan 9
Rebased on top of D28073
Fri, Jan 8
For reference, this is what an AArch64 QEMU virt machine shows in devinfo when using PCI:
@bryanv Does this seem sensible to you? It's a cleanup/simplification I've been meaning to do for a while as the current situation is a bit silly, unless there's a reason you can think of why this is a bad idea?
Thu, Jan 7
Mon, Jan 4
Thu, Dec 31
@grehan Thanks :)
Wed, Dec 30
Everything those commits did is necessary for V1. It's not sufficient per the spec, granted, but having the commits to support _some_ V1 implementations is strictly better than supporting _none_. If you have commits to introduce the missing parts of the V1 feature negotiation sequence then add them, but don't revert what's already there only to reintroduce it later. Otherwise you will break TinyEMU and the FPGA-based system we have built atop its VirtIO implementation.