Simplify both macros EFPRINTF and EFFLUSH and remove the unnecessary variable 'err'.
Likewise, remove varible 'err' from some functions that uses those two macros.

Address @jhb issue regards with the respect of style(9).

In D15550#328333, @rgrimes wrote:

Please mark the commit as MFC-X with https://svnweb.freebsd.org/changeset/base/332298

oooops, I opened a revision with the wrong file 🗡

Sort one more header.

It breaks pci_emul in other places, needs further investigation.
I'm taking it.

Update this patch and fix the latest suggestions.

ops gratuitous change slipped in, I fixed that. Thank you @imp!

In D15421#326317, @rgrimes wrote:

In D15421#326315, @araujo wrote:

In D15421#325260, @rgrimes wrote:

Thanks for catch Roman, I have prepared a commit and sent it to my mentors for approval, with a fast track 3 day MFC as this made it into stable/11.

Wait! Do you just committed a patch sent by another developer?

@novel have you approved that?

Best

Yes, based on the facts: I was the person that committed the original bug, and @novel has a ports commit bit, so could not of committed this to src without approval.

In D15421#325260, @rgrimes wrote:

Thanks for catch Roman, I have prepared a commit and sent it to my mentors for approval, with a fast track 3 day MFC as this made it into stable/11.

In D15388#325307, @jhb wrote:

Normally if you weren't planning to do a runtime check you would just not have 'n' at all. What you really kind of want is a working version of 'assert(vq_getchain(...) >=1)' but you can't do that safely. Andriy is right that the warning will be back with a NDEBUG build (but we don't define NDEBUG in FreeBSD builds, even for releases). The current version is perhaps the least evil. Other ideas I considered:

if (vq_getchain(...) < 1)
    abort();

if (vq_getchain(...) < 1)
   assert(false);

Address @avg concern about idx becomes 0 and be passed to vq_relchain and perhaps
end up on vq_endchains with a bogus values.

Don't know why the review wasn't updated.
I just committed it: https://svnweb.freebsd.org/changeset/base/333446

• Remove blank line and add copyright for the initial work made by @jceel.

• Address the latest comments and fixed an issue with copy(9) on sys/cam/ctl/ctl.c.

Turn off debugs on pci_virtio_scsi.c, updated the review with this option on by mistake.

Address avg@, @bcr and @rgrimes suggestions.

In D15276#322033, @avg wrote:

I wonder if this can be made to work with pass devices.

Fixed a sentence at the example section that was changed by mistake.

Address @mav and @wblock changes requested.

• Restore again the updates on ctladm.8.

• Remove an unnecessary free() that was commented already.
• Initialize a variable to silence clang-analysis warning.
• Use realloc instead of malloc.

• Bring back ctladm.8 updated, removed by mistake.

• Fix kernel panic when use 'ctladm portlist' and 'ctladm port -l' because of the misusage of variable cookie on nvlist_next. The variable cookie must be set to NULL for the first call and should not be changed later.
• As we are inside KERNEL it is safer use dnv(9) and check if we have a return from dnvlist_get_string.

• Keep the on|off as option "o" or otherwise we will break POLA.
• Instead to use "o" for pp|vp we will use "O".
• Update manpage to reflect these changes.
• Also remove a unnecessary free() that was creating a core dump on ctladm.

• Update ctladm(8) manpage to reflect all these changes.
• Also reorganize the 'example' section where it should have first an explanation about the command line and then the command line example.
• Add at the example section some examples how to use the new options ioctl frontend.

Sync this patch with the latest HEAD revision, also bump FreeBSD version due API changes and to make it explicite incompatible with other versions.

I'm taking over this review as I need it to be able to add virtio-scsi for bhyve.
All the credits are still maintained for the amazing work done by @jceel

Please bump portrevision as there's a new dependency.

Lgtm!

Oooops! I completely forgot this patch, I will add capsicum this week.
My bad!

Lgtm! Feel free to commit it.

LGTM!

@allanjude Do you have any other consideration?

In D14286#299680, @allanjude wrote:

For this to work right, shouldn't we load /etc/rc.conf.d/pf and maybe ipf as well?

There is no man page entry, maybe we could use the same man page changes from review D13995?