I'm tapped out. Can't find anything else.

Looks a lot better. Found one minor thing...

Missed references.

This looks pretty close, but there are still a couple of issues that need to be resolved before the commit.

committed.... thanks!

In D18613#416846, @imp wrote:

Added license concern, but it shouldn't be a huge deal. haven't looked at the CAM integration yet.... That will come in time.
And in case it isn't clear, I'll drive the License issue inside of core.

In D20562#447322, @emaste wrote:

In D20562#447320, @emaste wrote:

Are they already unhooked from install?

It seems not - they're optionally not installed if NOFAT is defined (rS348722/rS348763). There are several ways it could be accomplished (e.g. change to #ifdef EFIFAT) but my suggestion is that by default we do not install them and move the entries to ObsoleteFiles.inc unconditionally. Folks with out-of-tree uses can just do something like (cd stand/efi/boot1 && make -DEFIFAT)

In D20394#444447, @adamw wrote:

In D20394#444436, @mat wrote:

In D20394#441905, @kmoore wrote:

Anyway, open to suggestions on where to next take this conversation to reach some consensus around these topics.

The consensus is that this does not belong in the ports tree.

I want to piggyback on this. The ports tree needs to be about ports, and it just doesn't make sense to mix src and ports in the same tree.

If I were you(pl.), I'd make a new tree for building src packages. It can piggyback ports/Mk, and with the addition of some src-tree Mk/Uses files you should be in business. The process and resources are identical, but it should live in its own tree.

To build pkgs out of src, I would have suggested calling it /usr/pkgsrc but that name means something else :-)

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?