Merge in comments for the KERNLOAD into one blob.

Updated, thanks @markj !

Eliminate KERNEL_PHYSICAL_BASE althogether, move #include <machine/vmparam.h> into i386/amd64-specific section.

In D26526#590868, @markj wrote:

Looks ok to me, my comments are just nitpicking.

Thanks Ravi for suggestion, it has been incorporated.

Clarify intended use case for the new option.

Thank for a review Mark! 4 out of 5 suggestions have been incorporated, please check.

Reset do_log_reopen earlier, so that we don't stuck in a loop calling this function repeatedly if error happens.

Use signal handler in a safe way.

@imp any chance you can review and see if the change can land or indicate what other changes are necessary. Thanks!

@imp the requested changes have been applied. Please check. Thanks!

Collapse .if/.else/.endif into one liner.

Might need ("partial?") MFC into stable/11 stable/12.

In D22099#482956, @brooks wrote:

I believe the correct way to handle this is to update the vendor tree and then merge. I'm happy to do that.

Is this only in the new version I imported on the 8th or do we need to MFC as well? If the latter, I suspect it makes sense to direct commit this patch to 12.1 rather than doing a full update this late in the release process.

Document usage scenario bit further. Fix some mandoc formattings nits. Suggested by @mckusick

I will keep it at reviews for 1 week and then it will land unless major objections are received. Thanks!

Hey @imp can you please review the latest revision and confirm that it looks OK now?

Rename MTREE -> DISTR_MTREE for clarity and in hope to make @rgrimes happier.

In D20520#443376, @imp wrote:

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

src.bootools.mk -> src.tools.mk as suggested by @imp

Looks good, as long as it compiles.

Looks good to my VFS-naive eye. Thanks!

Overall looks like a good start, however there are some things that I personally dislike:

Not sure why this is still open. @mizhka_gmail.com please GC?

In D19707#422201, @kib wrote:

Your 'fix' is not enough even for mtime. Look at the tmpfs_sync(MNT_LAZY).

Check read-only flag in an unified manner.

In D19682#421511, @kib wrote:

As I understand, currently ro tmpfs mounts are useless and the code is incomplete. I did very quick look and the first VOP I looked at, tmpfs_mkdir(), seems to allow modifications of the ro mounts (this is from code reading, not from testing). Was code review done to ensure that read-only tmpfs mounts indeed operate as intended ?

In D18586#397007, @mckusick wrote:

Given that this plausibly works only with two different /etc/fstab files, I think your change should also include an update to the manual page to explain how the update keyword is intended to be used.

Document "update" option, as suggested by @mckusick

In D19266#413225, @kib wrote:

Rebase; fix conflicts.
Formatting and comment changes.

In D19266#412957, @kib wrote:

In D19266#412909, @cem wrote:

In D19266#412904, @sobomax wrote:

geom_uzip(4) uses zlib module without the need to add dummy "device zlib" into kernel, why xz code should be any different?

zlib is built if geom_uzip is enabled in conf/files:

libkern/zlib.c                  optional crypto | geom_uzip | ipsec | \
        ipsec_support | mxge | netgraph_deflate | ddb_ctf | gzio

(Also, zlib has many other consumers. xz-embedded has limited general utility, due to being a decompress-only subset of lzma. So I am not sure xz will gain many more consumers. I agree adding 'device xz' to a million MIPS kernel configurations is an ugly repercussion of this choice.)

What you cited is clear example why I (and others) do not do this dependency tracking insanity in the conf/files syntax. Config(8) is only effective at flat dependencies where all required config options are explicitly provided in the kernel config file. Tracking dependencies like turn on B when A is on, but also consider side effects from C, D, E, architecture, and so on, is impossible with it.

I thought it is obvious that the only reason why I wrote this patch is because there are more planned consumers of xz in kernel, which alone is the reason why I want it to be a dedicated option, and why I want (need) to avoid the dependency drama.

Also see the recent discussion of iflib modularization.

That said, are there any other _technical_ notes about the diff ?

In D19266#412644, @kib wrote:

Remove 'device geom_uzip', add xz to notes.

Also "device xz" needs to be added to the conf/NOTES.

Looks good overall. I am little bit puzzled over usage of "option GEOM_UZIP" vs. "device geom_uzip + device xz". I suspect those are functionally equivalent. Half of the kernel configs in the tree use former (including NOTES) and half the latter. Some subset of the two use both. :( Since you are touching those files anyways, perhaps you can go and convert all cases of "device geom_uzip" into plain "option GEOM_UZIP" and not patch it up by adding device xz? It might be also a good idea to adjust geom_uzip(4) accordingly to provide "One-True-Way" to compile geom_uzip(4) statically into the kernel? Thanks!

In D18382#398850, @eugen_grosbein.net wrote:

In D18382#391348, @sobomax wrote:

o Due to popular request rename "erase" into "trim".

You need now fix clist[] array in the args.c as it must be sorted or else bsearch() fails to find "trim" and dd conv=trim bails out with error "unknown conversion trim".

Keep clist[] array in the args.c sorted by the name so that bsearch() DTRT.

In D18586#396514, @kib wrote:

So what happen when somebody run 'mount -a' second time, with non-idempotent mount option + update ?

In D18586#396505, @mckusick wrote:

This change does not seem wrong, though the only way I can see it being usable is to have the read-only mount's in /etc/fstab, then a special fstab that has the desired update mount lines in it.

In D18546#395707, @eugen_grosbein.net wrote:

In D18546#395642, @sobomax wrote:

2. At some point administrator logins and changes MTU from value X prescribed by the DHCP to some other value Y of his liking.

JFYI: the PR 229432 mentiones working way to ignore option 26 (MTU) supplied by DHCP server:

interface "em0" {

supersede interface-mtu 0;

}