I tried a similar version of this change and my eMAG reports CPU 0: APM eMAG 8180 r3p2 affinity: 0 0
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 21 2019
You've build-checked this, right?
Yes on amd64.
Aug 20 2019
fat.h deduped in D21346
shuffle includes to avoid struct declarations
mounting the ESP at /boot/efi LGTM, this will give paths like /boot/efi/EFI/... but this is consistent with what Linux distros do
rebase and remove extraneous changes
Aug 19 2019
Aug 16 2019
This change is not valid, it removes the templates but leaves the Makefile rules in place to install them.
LGTM other than the minor comments inline
rebase, add inline as suggested by @delphij
This is just another "upstream only considered Linux, we need to be included in the same way as Linux" case.
Can you show a diff of the NetBSD version to this? i.e. what you had to change in the port?
(I assume that we don't want to treat this as contrib code and will just adopt it.)
Wrap in .if !defined(_SKIP_BUILD)
(I've looked over the change other than the just update dictionary section so far)
Aug 15 2019
No objection from me
As it turns out gptzfsboot is identical, whether GAS or IAS is used to assemble gptldr.S:
all other boot components have been addressed; only gptzfsboot needs to be investigated now
rebase after committing boot2 and cdboot changes
cdboot in rS351092
cdboot differences are a large number of addr32 prefixes and using nop nop for alignment rather than xchg %eax,%eax, so it is ok too
Do we know if the differences are similar there as well?
rS351073 for boot2
side by side comparison with the .o generated
Aug 14 2019
Aug 13 2019
In D21110#461916, @asomers wrote:Submitted as r350665. I don't know why Phabricator didn't close the revision automatically.
Aug 12 2019
In D21232#461469, @imp wrote:These are fine but (a) you need to have mount privs to execute this ioctl; (b) nandfs is a panic trap due to bad locking and the system can't stay up once there's any vnode pressure at all; and (c) the set of nandfs users is the empty set due to (b). This is not exploitable in any meaningful way.
Seems reasonable to me. I might expand the comment slightly to "prevents a MITM attack on the dependency."
Aug 8 2019
@ngie will you commit this?
Looks like this was broken in rS336439