blacklist
don't reload unloaded drivers, part 2

Suggested UPDATING entry:

Generally, I like what's presented here. There's much we need to cleanup, I think, but this is a good start.

In D16775#357085, @jhb wrote:

As far as std.arm*: I don't know why it only has options. It seems to me that 'std.*' files should be fine to have devices as well. Note that 'std.MALTA' in sys/conf/mips has both devices and options. I think moving "standard" devices into std.arm* to reduce duplication in kernel configurations for things that are a truly "standard" thing (which pseudo-devices probably are) would probably be a good thing, but that probably needs to be run by Warner.

This looks ready to land. We need to get it in in the next week.

• fold devctl prog
  • Stupid debug
  • Allow NULL to be passed into the device name to send the message

• Improve devmatch driver loading
• Remove sorting of matches and print all the matches as we find them.
• First cut: Untested kernel bits

Why? Some words of justification are needed since it's not obvious to me why this is a good idea...

seems reasonable to me. Haven't looked at the man page though.

Why? It's been like this for 20 years...

Generally, I like it. I've wanted a feature like this. I haven't looked at every single detail and just commented on what in a quick pass stood out.

Modulo the https://reviews.freebsd.org/P209 I suggested, and maybe a stray include of isavar.h, I think this is good to go.

In D16740#356185, @jmg wrote:

Should powerpc64 be added too?

(I'm not familiar w/ it, so don't know how heavily used GPT is there.)

fixed and regened

fix typo and while I'm at it, adjust comment

I like this. Make sure that smartmontools is updated too. It likely adapted to the crazy API that we had for a while...

i386m too

Looks good to me. Not sure if we want to encourage smaller patches where it makes sense, or if that's covered elsewhere.

-Oz is even better, but clang specific

This strikes me as two different changes. One for the phys_avail_reserve() and another to use it for the pci early stuff. I'm a little uneasy with the pci early name, but the code is clearly PCI specific.
Would there ever be a need to do things like this when running the 32-bit kernel? I know we don't support graphics cards there, but when we're bringing in new interfaces, it's a question that suggests itself.
RPi has this sort of thing too, but it's dealt with in the bowels of the FDT code...

I think that https://reviews.freebsd.org/P206 addresses the 'bogus' issues, as well as fixing some new whines that my mips build is showing.
Comments?

no, really fix pxeldr

Fix pxeldr for rename

After reconsideration, go with Rod's suggestion...

wordsmith

In D16705#355216, @rgrimes wrote:

In D16705#355079, @rgrimes wrote:

In D16705#355071, @imp wrote:

In D16705#355069, @rgrimes wrote:

Would there be an objection to using SUBDIR names of loader.4th, loader.lua and loader.simp so that they sort next to each other vs the current names that scattter them about the directory? This also means that loader.foo/Makefile simply includes ../loader/Makefile all nice and orderly :-)

I would object.

We can't install them as loader.lua, loader.4th loader.simp because then we'd have loader.lua.efi, loader.4th.efi etc. Also the .4th suffix is what we use for actual 4th code. So that leaves us with a prefix, even if it is a bit less orderly.

Ack, ok simple enough reasoning.

I thought about this some more and have another proposal, that IMHO address your issues and brings a good gain of order to this, my mistake was I used a . to express the separation, but if you use a _ then things are orderly loader_{,lua,4th,simp}{,.efi}. This matches much closer the variable names (MK_LOADER_FOO),
the source directories could be named similar, and the installed binaries match source directory names. It renames /boot/loader to /boot/loader_forth too, which IMHO is good now that there can be N flavors of it.

Update for efi

In D16705#355069, @rgrimes wrote:

Would there be an objection to using SUBDIR names of loader.4th, loader.lua and loader.simp so that they sort next to each other vs the current names that scattter them about the directory? This also means that loader.foo/Makefile simply includes ../loader/Makefile all nice and orderly :-)

In D16663#354801, @scottl wrote:

I think that this is going in the right direction. The SSU/shutdown code in mpr/mps is still not great, IMHO. There's a completion handler for the SSU CCB that could take care of decrementing the SSU_refcount, but instead every I/O is checked for the SSU state in the normal command completion path, and the refcount decrement happens there. The cost of checking every I/O for the uncommon shutdown case is probably in the noise right now, but if we ever want these drivers to do millions of IOPS, it'll need to be addressed. Also, error recovery is going to be highly problematic. Protocol-level recovery is non-existent because the completion handler doesn't call cam_periph_error(), but transport-level error recovery (for things like timeouts) will likely still be called from the driver. Do we want error recovery to be triggered during a system shutdown, possibly triggering extra delays? If an error does happen, does ignoring it make the device problematic the next time the system starts up? If we want the driver to ignore transport level error recovery, how should that be flagged?

Looks great.

Let's continue this in D16663

Amendment to my prior thing. We'll need a cam_sim_poll() function. We have to call the sim_poll function, and the call camisr_runqueue() and there's some 'hidden' locking that goes on... I'll open a review with cem, markj, scottl, ken, asomers and mav with it and the fixes...

In D15592#354117, @cem wrote:

In D15592#354014, @imp wrote:

In D15592#353902, @cem wrote:

So the concern is that the dumping && SCHED_STOPPED check may be too narrow. dumping is cleared when doadump returns. And e.g., the shutdown_final event is invoked during panic reboot. Many(?) (some, anyway) disk controller drivers register eventhandlers that attempt to submit CCBs during shutdown.

There should be no problem with them doing so. Again, there's some I/O that's not read/write that's necessary to properly shutdown some devices (even if the request doesn't make it to the drive itself, since the firmware on the disk controller intercepts it and does its own magic). We absolutely must do this I/O, even in the case of a panic, or data loss will result. It's my understand that it's really non-optional. It's the basis for killing the 'do this at the CAM layer' argument.

The problem is that they will hang forever if they wait for an interrupt-driven CCB completion during panic — preventing reboot. After dump completes, nothing is polling.

Make changes suggested by kib. abandon the _DIAGASSERT update and
instead comment things out and then do a separate commit to do minimal
cleanup.