- User Since
- Sep 10 2014, 9:01 PM (360 w, 1 d)
Jun 26 2021
Jun 23 2021
Thanks for spotting this!
Jun 2 2021
I *think* this will be fine if the equivalent code moves to PPC nexus (where it came from in the first place long ago).
May 28 2021
May 14 2021
May 7 2021
Looks good to me, assuming it works anyway.
May 6 2021
Overtaken by events long ago.
Apr 29 2021
Looks good to me. Thanks! There are probably more instances of this kind of thing lying around.
Apr 27 2021
Apr 16 2021
Apr 15 2021
Apr 12 2021
Apr 7 2021
Nope, that's broken too in the same way:
Apr 6 2021
This update doesn't actually work, though it does build:
Thanks, fixed 0/1->false/true.
More diff context, no functional changes.
Apr 5 2021
Fix some fat-fingering and rename an argument to better reflect what it does.
Instead of adjusting parameters when generating VM images, adjust makefs to make free inodes when making free space. Relevant code copied from newfs(8).
Mar 30 2021
So makefs(8), by default, creates a file system that can exactly hold the input tree (no extra space, no extra inodes, no extra anything). If we change the defaults in makefs(8), it seems like there are a few options:
Mar 29 2021
Mar 28 2021
I should also mention: one other path here is just to delete loader.kboot, since I'm not really sure it's useful. Even my PS3 loads the kernel directly from petitboot these days.
Thanks! This looks basically sane. I'll try to smoke-test it in the next few days; if I don't report back by Wednesday, treat this comment as approval.
Mar 26 2021
Mar 23 2021
Mar 22 2021
Fix missing newline.
Mar 19 2021
Mar 11 2021
Mar 10 2021
Mar 9 2021
Mar 6 2021
Mar 4 2021
Mar 3 2021
We could also have makefs use expand_number(3) instead. Apologies for breakage!
This patch looks good to me from a technical point of view. I have no opinion on /boot/efi vs. /efi, so won't comment on the ultimate merits of the change, but you're welcome to include a "Reviewed by:" from me if this goes in.
Mar 2 2021
Feb 25 2021
Just committed this. I agree about 13.0 -- I was planning to merge to stable/13 after 13.0 has branched and smoke-test this in HEAD for a bit in the meantime.
Feb 24 2021
Feb 23 2021
Now tested and working, with UFS and ZFS, including multi-disk ZFS setups. In principle ready for commit.
Now does ZFS (including redundant setups) as well. Still not fully tested.
@imp any thoughts on the gmirror solution for ZFS? I think it solves 95% of the update issues and shouldn't be too bad to implement.
Feb 20 2021
Just to be pedantic: We actually *do* have /boot as separate on some systems (e.g. recent powerpc64), but those systems are mutually exclusive with EFI systems. I have a mild preference /boot/efi, but it doesn't really matter much so long as we pick something -- the status quo is it not being mounted *at all*, so reliability of mounting or whatever is obviously a second-order issue.
Dec 17 2020
Dec 13 2020
Oct 29 2020
Oct 15 2020
Jul 6 2020
May 12 2020
May 10 2020
Do we know all supported 32-bit AIM CPUs do the same things with DSISR? Otherwise, it looks good to me.
Dec 1 2019
Nov 30 2019
Sep 7 2019
I have pretty mixed feelings about this approach. It only works for ofwbus children, not simplebus children, and canonicalizes a bunch of behaviors that I don't believe are standards (I'm in an airport departure lounge and don't have the spec handy). I'm also not really sure how it interacts with multipass etc. Could you elaborate a little more on the mechanism?
Aug 27 2019
Aug 26 2019
Fix fat-fginering; this is the right diff. It also sets Python to use Python 2, since a handful of scripts cared.
Updates from review.
Aug 25 2019
Jul 21 2019
OK, sounds good, thanks for testing!
Jul 15 2019
Just make the page table size really small. There's a spill counter in the statistics; when it gets small enough, you should see it moving. If spill-handling doesn't work, and you have spills, everything breaks fast.
Does this break PTE spills? This code path historically was involved in re-adding PVOs to the hashed page table on faults if they got spilled.
Jul 11 2019
That's a fair point. I've used them to assess hash-table spill rates when performance is not great, but not for a long time. We could also just delete them.
Yeah, counter(9) seems like the actual solution here.
Jun 19 2019
Looks good to me; do you know how much this actually helps?