Looks good to me.

Looks good to me.

Looks good to me.

Nice work! I agree about the #if 0 section, though -- please remove it when you commit.

Looks good in general. One comment regarding Marcel's comment 2: I think all the codes are already unified, actually.

Looks OK to me. Would be nice if you changed the name of the "phandle" argument to "key" or something since, in the cases where this applies, it isn't a phandle.

PowerPC bits look good to me.

Generally looks OK but see inline comment about cpufreq.

This is a good patch. The spec defines that interrupts properties are in 32-bit chunks "encoded as with <encode-int>" (i.e. big-endian and 32-bits at a time), so all endian decoding should be confined to OF_getencprop() calls in ofw_bus_intr_to_rl().

Committed in stages to HEAD.

Sorry, was traveling. Looks good to me.

Looks good to me. Thanks for doing this!

Could you elaborate more on what this does? I'm not really sure what the goal is relative to platform drivers that iterate through the tree (this is how PowerPC and sparc64 SMP work) or subdrivers (like cpufreq) hanging off the CPU hierarchy.

I'm reasonably satisfied that it won't cause regressions now, since we've tested on UP and SMP 970, Cell, and the POWER simulator. If you won't have time to test on POWER hardware in the near future, and you think the approach here is reasonable, could you mark this "Approved"?

Could you try again post r277468? There was a bad interaction between some of the changed compiler flags and the hacked-together HID register restore sequence in mp_cpudep.c that I just fixed. I hadn't noticed the problem earlier since I wasn't using 970 based hardware. My G5 powermac now runs fine with a dynamic kernel.

That should be right. You should be able to apply just the machdep.c, trap.h, and trap_subr64.S parts of the patch to see if the problem is there. Each section of trap_subr64.S is also independent if you have the time to bisect. I'm very confused about why your hardware and mine are different. You see the AP #1 launched message OK?

Messed up the last diff. This should fix the SMP/Altivec issue in any case.

I think I found the SMP issue, which was actually a CPUTYPE issue. There was an extremely subtle problem in the trap code that would cause a double fault on the first altivec instruction issued from userland. Fixing it is horrible, as it requires that trapcode be at most 8 instructions, which it now is. This comes up successfully on my hardware now. A retest on yours would be much appreciated.

Andreas: which version of the patch did you try? It seems to work OK on my SMP hardware here.

Updated to not __CONCAT for the SPRG instructions. Additionally, since ABSOLUTE_JUMP was only being used in one place, I just expanded it in-place.

The patch looks good to me. Thanks for the reminder about the CPU id; most of the PowerPC code doesn't assume they are continuous (they aren't on many systems), but this erroneously does.

Looks good to me.

Nuke it. I don't think it was necessary even when it was added. Thanks!

This is definitely an improvement compared to gnop and should go in the tree. The whole issue of 4K sectors should go back to the mailing list, however. This is useful only for pools that get upgraded with 4K disks in the future; in all other circumstances it is harmful.

Looks good.

I discussed this with Ian on IRC yesterday, but for posterity: we should remove this eventually and replace it with a copy of OF_decode_addr() from /sys/powerpc/ofw/ofw_machdep.c, which already handles all the cases and is quasi-standard in the tree.

This looks great to me!

That looks perfect to me. Thanks!

Mostly looks good to me. I'd phrase a few of the points in a more positive way, though, and also define the terms. "No modesetting" makes it sound like KMS isn't supported, for example, which it most certainly is.

The keymap selection is the important bit there, I think. The installer keymap selection got rewritten as part of bsdconfig, so I no longer know how it works. Maybe Devin can take a look?

I agree too. Not an MFC candidate, but something that's a good idea. vt supports at least all of the hardware that syscons does now.

There was a discussion on this on the freebsd-fs list in June (e.g. http://lists.freebsd.org/pipermail/freebsd-fs/2014-June/019535.html). The consensus seemed to be that forcing the ZFS block size to larger than the stripe size was actually harmful in many cases and that this feature should be removed entirely rather than shifted to use the sysctl.

What happens on systems with no battery? For example, desktops?

Nice work! I do wonder (this is out of scope, however) whether it is worth standardizing some of these interfaces. Hopefully various ARM hardwares (Chromebooks, for example) will acquire the same features.

Right! Then we should keep that.

This will probably break all non-FDT Open Firmware platforms, which do not include anything in sys/dev/fdt into their kernels. It's possible that the change to conf/files.powerpc fixes it, but it highlights a more general issue: there is nothing whatever FDT-specific about the code. Could you move the function into dev/ofw/ofw_bus_subr.c? That's where these things belong.

Check the box: this looks great to me.

Looks good. Thanks!

Looks good to me too, though I don't know anything about dtrace.

I like the approach. It builds and works on powerpc64 11. It probably does need a test, but otherwise it looks good from my end.

Looks good!

Should we have #if !defined(i386) && !defined(amd64) instead of whitelisting powerpc and arm? The stuff not being included is very x87 specific. Or use the gnuc99 fenv support, which looks like it's MI?

Looks perfect. Thanks!

One minor thing: I think (per uefi.org), it's "UEFI" not "uEFI". Otherwise, this looks fantastic. Thanks!

That sounds like a good plan to me, Julian. I'd just like to see these things done piece by piece and well thought-through. Aside from the minor nits mentioned, I'm quite happy with the changes.

I really don't want to argue about code length here, but, for clarity, my line count removed whitespace and comments, which are about half of the original code.

Julian, I agree. That's why I first asked what else this was for. If it's a general purpose tool that adds really useful features and this is the first use, that's absolutely fine. It would be nice to work with upstream to make this a part of libdialog itself, though, rather than wrapping it.

I didn't do a shell script in the beginning because it was hard to feed status information from tar into dialog in a sane way. Since the alternative 160 lines of C didn't require gymnastics, that seemed like the safer and more maintainable approach. distfetch is in C for the same reason. Any approaches that are even shorter/more robust would be good alternatives to the existing code.

What else is this library for? I don't necessarily have any objections to the patch per se, but it's a huge amount of extra code to this otherwise very simple libarchive frontend to add an extract speed status bar, which for extraction (and opposed to downloading files) seems like something of pretty marginal utility.