I have a vague notion of doing this before...

In D54117#1236396, @des wrote:

In D54117#1236374, @imp wrote:

This is what I've wanted to do for some time now. I didn't look closely enough, but so long as fastboot gives us the current behavior, (aka the -f behavior), I'm good with all this.

That is not currently the case, but that's fixable.

This is what I've wanted to do for some time now. I didn't look closely enough, but so long as fastboot gives us the current behavior, (aka the -f behavior), I'm good with all this.

Offline we talked. I'm totally cool with whatever so long as I can override the forced clean.

So I need to make sure there's not a blast radius on this one.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

ISO_C_VISIBLE: Interfaces available. It's set unconditionally based on the dialect. It's an undocumented interface.
STDC_VERSION: the exact dialect being compiled for. This is standards defined.

Why can't we make virtio_p9fs.ko depend on p9fs.ko? That would also cover this case, no? And would confine their visibility to that one module, no? It's how we do pci, etc.

Is it possible to create a branch for the whole chain somehow?

Looks generally good, but I did have one question...

both user and kernel, though there's no MK_REPRODUCIBLE_BUILD for user.

better wording for the triv copy routine

mixes a couple of different things, but they might not be as independent as I'm thinking, so I think this is fine from that perspective.
The workaround looks to match the one in Linux well enough I think it will work. The code bases are different enough that I didn't do a detailed copying analysis since direct copying between these drivers is kinda hard in structure, but is easy because the #defines are necessarily the same which has little to no copyright protection.

So why can't the coonsumers of these symbols just depend on the module? Why do we have to export the symbols from these modules to everybody?

In D53980#1233328, @des wrote:

In D53980#1233312, @imp wrote:

Oh that's what you meant. Why wouldn't it be in scope?

Because ever since someone¹ added tools/build/test-includes/Makefile to our tree four years ago, we test on every buildworld that most headers can be included without prerequisites, and <sys/_types.h> is included by <sys/_callout.h> which is included by <sys/callout.h> and none of those includes <sys/cdefs.h>.

¹ that someone was you

Oh that's what you meant. Why wouldn't it be in scope?

In D53968#1233156, @markj wrote:

Do we still need to maintain contrib/jemalloc/FREEBSD-diffs?

OK. I understand adding the quirk. It may make sense for us to handle some of these 'probing' commands better in the future, but we have many others than the ones you've added. As such, lets go wit the the PIM_WLUN flag for now.

Since only the SIMs that support WLUN reporting call this, that limits the damage.
It may be the case we have to probe LUNs first and not probe WLUNs at all if that fails (some older, reduced command CDB sets don't have REPORT LUNS at all). For the moment, it's fine.

Looks like a lot of whitespace changes unrelated as noted.

maybe add a fixes: tag?

I'd be tempted to do separate commits, but it's not therrible if not. The change looks good to me.

Dnssec just ensures the ip addr is legit. Https ensures the identity of who you are talking to as well as doing crypto.... we also independently sign the pkg, true. But the more barriers to spoofing the better.

Ideally, you'd upstream this too...

Why not

bool device_has_children(device_t dev) {return (!TAILQ_EMPTY(&dev->children))) }

update per review

memmove -> memcpy is the right thing because sn and cddata->sn can't possibly overlap.

Just a few questions. I started this review a few weeks ago then it slipped my mind...