Looks OK to me. One possible nit

I've not looked deeply into this, but it seems to my limited understanding in the right direction, though I'll defer to hps@ should his opinion differ.
Just noted a couple of nits, plus there's some minor style issues with some of the code that we can get into once other comments are made to the source.

yea, this never should have been in boot_module.h to start with.

Nits

Added emaste as a sanity check for the 'not used' bit. I'd like to see this die in fire.

In D20293#444094, @ian wrote:

In D20293#443814, @hselasky wrote:

I agree about that, but as you know the TTY layer holds a mutex while calling us, so sleeping is not allowed or am I wrong? You don't solve mutex problems by just dropping the TTY lock, that leaves races wide open.
I suggest a new method in the ttydevsw which drain any pending commands off the underlying layer, which can be called outside the tty_lock() so we don't mess with the TTY's internal state.

Oh right, I had forgotten about tty_lock() being held during calls to ttydevsw stuff. Now I remember looking into all this once before, a few years ago. What I discovered (and re-discovered yesterday) is that lots of places now are dropping and reacquiring the tty lock, unsafely. At a minimum, you have to check tty_gone() after recaquiring it. In addition you have to consider the other parts of tty state that the lock protects and what might have changed there, and that's hard to do because what the lock protects is not documented.

In D20116#443964, @cem wrote:

The concept is cool but it's impossible to closely review 2000 lines of novel content.

In D20031#432425, @shurd wrote:

Use rtsdtr as the stty argument to set the default mode, and -rtsdtr to
disable automatically asserting them on open().
This causes the stty argument to have the opposite polarity as the control
flag. The stty flag name can be renamed fairly easily, but the control flag
pretty much needs to default to zero.

I'd just roll with this. IMHO, the simplicity trumps the other patterns in the file because using the pattern here gives no real benefit.

bootools is a terrible name, so bad I'm ticking 'request changes'.

In D20458#443364, @cem wrote:

In D20458#443358, @avg wrote:

I would like to commit this change as is now. And then change printf to KASSERT in a week rather than in a month.
Hope that no one would object.

Ok by me.

In D20458#443359, @avg wrote:

Also, another thing that I realized is that this defensive code won't help much if a bus defines BUS1_IVAR_X and a child device requests BUS2_IVAR_Y when BUS1_IVAR_X == BUS2_IVAR_Y.
BUS_READ_IVAR / BUS_WRITE_IVAR may succeed in that case but the result could be meaningless.
The only idea I have is to start gradually introducing a pattern where a first value of an ivar enum is some randomly chosen number.
E.g.:

enum {
        IICBUS_IVAR_ADDR = 100500,      /* Address or base address */
        IICBUS_IVAR_NOSTOP,             /* nostop defaults */
};
enum smbus_ivars {
    SMBUS_IVAR_ADDR = 100600,           /* slave address of the device */
};

That might help to minimize a chance of an accidental ivar value clash.
But changing this for existing ivars would break the ABI.
So, I guess, that we could start doing this only for new bus devices.

Could do something cute like compile time hash of svn/git rev + bus + var name? Would require some makefile support or a c++1x constexpr compilation unit with extern C visibility (depending on how much we care to detect this). Obviously svn/git revision would be frozen at stable branch. Maybe too cute for little benefit.

In D19746#443110, @chuck wrote:

The change looks reasonable to me. Are there any ABI issues with changing the size of struct cam_sim?

In D20506#442950, @danfe wrote:

Warner, do you want me to update the diff to use return (&DEVTOISA(child)->id_resources);? I'm a bit worried that it would cause more repochurn compared to the current diff which only removes the lines and thus does not affect svn blame on the the others.

This change should do what it says it will do.
Let's see if we can get a bunch of 'works for me' reports from testers :)

It's never needed it

On second thought, I'll use the tunable.

I think this is good, thought I thought'd I'd committed the PARTWILD stuff already. Are there more places I/we've missed?

better comment.

Remove now-obsolete comment.

In D20480#442157, @emaste wrote:

No objection but I'm generally not a fan of the deferred evaluation; what about just setting include_metadata=yes/no/if-modified and making the test something like
if [${include_metadata} = yes || (${include_metadata} = if-modified && ${modified} = yes)]
Anyway if you prefer this approach that's fine with me

Fix per ed (though a little different construct)
Fix backwards test after converting from -z notation...

Plug more holes with tips from kib, jhb and markj.

Try a little harder, add comments.