Unfortunately, there are some big drawbacks to this approach. The larger you make the chain frame pool, the more pressure you put on the contigmalloc allocator. This is usually (though not always!) not a problem at boot, but would be a big problem with loading the driver as a module after boot. I agree with the desire to make the chain frame pool be self-tuning, but I think that to do it the right way, the pool must be allocated in multiple smaller segments of no more than 2MB each (i.e. 16384 frames). It should also handle potential allocation failures. Without this, I feel that your approach will be too fragile.

In D14063#298088, @mav wrote:

I neither have major objections aside of one inline, nor too happy. From one side I agree that there is no any/much sense to return cam_status from functions like that, which do not work with command statuses. From the other side it is a) an API change, which may lead to difficult to find errors, but b) there are many other functions suffering the same problem (but which may be more invasive to fix though).

Good find on this. I've seen queue-full conditions in the past but hadn't tracked down the causes; I think this is it.

I think you forgot to add the implementation for CAM_PERIPH_PRINT(). Mine looks like this in cam_periph.h:

Something in this patch is causing my system to spontaneously reboot late in the boot process. No panic, and the messages on the screen disappear too quickly (and are erased in the serial console by the BIOS splash screen).

Looks good to me. I'm OK with removing scsi_low and all related code for FreeBSD 12.

I came across it during some other clean-up work.

Resolved in r322943

Rewrote the xpt_announce_periph and xpt_denounce_periph functions, the
previous work tried too hard and failed at code sharing. Also add in
seatbelts for transports that don't support sbufs yet, and add a tunable
knob to force the non-use of sbufs

Pending our discussion on IRC, would you mind if I took over this review and extended it?