Update default and sysctl language.

Sorry, it occurs to me that I probably misinterpreted about dumping. Assuming previous transfers are aborted/cleaned up, we should probably make sure the platform driver doesn't handle that.

Thanks for your patience with me for delays in my end.
Looks good and I think we're good to go.

Rebase after r354968.

Ping. Can you confirm that this works ok with Linux guests? Also, any sense of making forward progress on using block_if_can_delete()?

In D22430#491639, @marius wrote:

I'm inclined to say that this change is okay, I'm having problems to understand its motivation, though. First off, bcm_sdhci_intr() already wraps around sdhci_generic_intr() so I don't see why sdhci_bcm(4) shouldn't actually be able to nab SDHCI interrupts before sdhci(4) does. Granted, there's the case of sdhci(4) calling sdhci_generic_intr() directly when dumping. However, when dumping in case of a panic, the scheduler is stopped so the interrupt thread for bcm_sdhci_dma_intr() shouldn't get to run either. Thus, it's not obvious to me how panic dumping currently can work at all in the first place if sdhci_bcm(4) uses DMA for these requests.

My understanding is you need both mentor approval and src approval. Consider it src approved by me.

I'm inclined to say that this change is okay, I'm having problems to understand its motivation, though. First off, bcm_sdhci_intr() already wraps around sdhci_generic_intr() so I don't see why sdhci_bcm(4) shouldn't actually be able to nab SDHCI interrupts before sdhci(4) does. Granted, there's the case of sdhci(4) calling sdhci_generic_intr() directly when dumping. However, when dumping in case of a panic, the scheduler is stopped so the interrupt thread for bcm_sdhci_dma_intr() shouldn't get to run either. Thus, it's not obvious to me how panic dumping currently can work at all in the first place if sdhci_bcm(4) uses DMA for these requests.
Second, "platform-driven transfer [...] keeping the bits enabled in SDHCI_INT_ENABLE for internal handling" sounds like using SDHCI_INT_ENABLE as a mere scratchpad register in the platform-specific code. If that's what you mean, it generally would be better implemented using e. g. a variable or a member in the front-end-specific softc.

I think this is fine, but can you explain the "114 option is already in use for undisclosed purposes at Apple" in more detail?

added Mark as most recent committer in this area

either you or mat or tcberner approve of it as well, or some src committer will have to commit on their own

I'm ok either way, thanks for catching this.

Where is this optimization actually used ? Almost all calls to vm_pager_has_page() pass NULLs for behind/ahead.

Hi Mmel,

• New snapshot

Hi Rebecca, Ed, this hopefully follows on from the HTTP boot work already done.
If you can suggest better reviewers please let me know. I'd like to MFC this
to stable as well if all is accepted.

This allows a suitable DHCPD like ISC-DHCPD to string option 114,
and have the client receive in its DHCP parameters, what HTTP boot
URL was used. Ideally the kernel will know how to pass this data
through from boot time, but this is a reasonable starting point
to at least ensure the option is readable when dhclient itself
starts up.

Add option handling to lookup table

In D22425#491434, @linimon wrote:

This is simply above my pay-grade.

In D22464#491516, @kevans wrote:

In D22464#491447, @arichardson wrote:

In D22464#491412, @kevans wrote:

In D22464#491409, @arichardson wrote:

LGTM. Only concern might be that adding /usr/libexec to PATH adds too much stuff.

Hopefully I can get the strict tmppath usable by default soon so it shouldn't matter anymore then.

Yeah, so what I really wanted here with flua was some way to indicate that flua can/should be symlinked in from the host (preferably to the same location that I've added to BPATH) on the versions it's *not* being bootstrapped (__FreeBSD_version after I added it) to simplify this, since I don't really want to add /usr/libexec. Any advice on making that happen (or just getting flua into one of the standard BPATH/XPATH paths while leaving it installing to /usr/libexec) is quite welcome. =)

It should be possible to modify tools/build/Makefile and change the host-symlinks target to add a flua symlink if it exists on the host.
Something like (untested):

.if exists(/usr/libexec/flua)
    mkdir -p ${DESTDIR}/usr/libexec
    ln -sf /usr/libexec/flua ${DESTDIR}/usr/libexec/flua
.endif

Yeah, I like that, thanks! I think the mkdir -p can safely be omitted -- we create it in the installdirs target now in case it's bootstrapped, which should always be run prior to host-symlinks if I understand correctly. If we later determine flua needs to be bootstrapped, that just gets built+installed over the symlink, right?