Not sure I like another special case. Please consider this instead. It would also correctly detect this at compile time.

My eye didn't trip over anything...

I like this. I'll echo the concerns of how to build both in one tree, but this allows either/or choice which is the next best thing.

looks good.

You listened to my prior feedback. This is perfect now. Thanks!

On second thought, when I commit this, I'll change it to bp->bio_cmd != BIO_READ.

This works. However, it points to a larger issue with the cam iosched. We're not careful about honoring BIO_ORDERED commands....

Fails for me:

my eyeballs didn't trip over anything here...

Change looks OK, but I agree with Ed, it would be better to do the white space changes separately.

Thanks for the changes. Now that my eyes are uncrossed, this looks sane to me now.

OK. All the bugs I found are fixed, and the gawk extensions are now implemented more fully. I intend to commit this, unless I hear otherwise.

back to master...

Looks like someone s/0/NULL in the context of a pointer,
so make it look the same.

Implement the gawk aribtrary number args for and, or, and xor.

Minor tweaks: fix error messages and pendantic white space issues.

In D12361#256383, @pfg wrote:

Minor tab/space issues but otherwise looks fine. Thanks!

In D10931#256082, @emaste wrote:

In D10931#256074, @eric_metricspace.net wrote:

I'm unsure as to what needs to happen now. Do I need to do anything to my patches yet?

We have D9860 open still which needs one more round of questions answered and updates, and then I'll commit that. After that I think it's all your patches.

In D10931#256082, @emaste wrote:

In D10931#256074, @eric_metricspace.net wrote:

I'm unsure as to what needs to happen now. Do I need to do anything to my patches yet?

We have D9860 open still which needs one more round of questions answered and updates, and then I'll commit that. After that I think it's all your patches.

In D11927#256075, @sbruno wrote:

Since this driver explicitly refuses to compile on non-64bit architectures (where LP64 is not defined), I'm moving this to files.amd64 as I suspect that this was what was intended. Else this breaks every FreeBSD build.

This looks good, but isn't the patch I expected from private email. I'll take a dry-run at committing it.

Now all you need to do is go through the tree looking for all the places that cartman is an alias for catman...

This looks good to my eye

Apart from the fact that this enshrines too much knowledge of how to make things bootable, this is fine (since it already knows and my stuff isn't quite ready).

Looks good to my eye.

Move all the white space changes to a separate commit
Fix some issues with returning the wrong thing
Simplify the system call (though I think we may just want to have a popen

to a script that knows all the cases and rip out most of the knowledge
from here so all creators of images / disks can use it).

Let the comments begin :)

This looks good, so far as it goes... But maybe effort would be better fixing bsdinstall to not suck so bad as to need this as one file it DDs into a partition.

! In D10447#254852, @eric_metricspace.net wrote:
That was because efi_main.c got moved out of libefi to loader. I moved it back.

Note: my question isn't a 'no' here unless the answer to the question is 'it totally works, what rock have you been under to not know that." :)

Once again I ask: where are we with makefs and FAT filesystems? :) Then we could kill these dreadful templates once and for all.

Wouldn't it be better to just remove gets.c from Makefile.inc?

This looks good to me.

Damn... You caught all the places I was being lazy :) I'll go back and try to fix them. Thanks!

In D12274#254694, @meloun-miracle-cz wrote:

Can be this MFCed to stable? In other words, do we support in place upgrade from 10 (soft FP ABI) to 11 (hard FP ABI)?
From my point of view, this is OK for FBSD 12.

It would be better to use a less predictable method of getting the next PID if you want random PIDs...

I have no objection, but am curious if we ever need to honor the mmsz.

Love it.

In D12211#253284, @rlibby wrote:

In D12211#253281, @imp wrote:

This is upstream code.
The warning should be disabled instead.

Whoops, didn't realize. I see lib/libefivar/FreeBSD-update now. So, am I reading it right then to understand that efivar-dp-parse.c is from an upstream, but uefi-dplib.h (modified in D12210) is just in FreeBSD?

I'll check if there's anything else to be done with the flags when building this.

This is upstream code.
The warning should be disabled instead.