In D16795#357283, @imp wrote:

Suggested UPDATING entry:

The default interpreter has been switched from 4th to Lua. If you have custom FORTH code
you will need to set LOADER_DEFAULT_INTERP=4th (valid values are 4th, lua or simp) in
src.conf for the build. This will create default hard links between loader and loader_4th
instead of loader and loader_lua (the new default). If you are using UEFI and it will
create the proper link to loader.efi.

In D16728#357097, @rgrimes wrote:

Though I disagree with the relocation of this to libc as it is going to be installed with the absolute minimal system anyway so this delta just creates src tree churn, and user finger memory churn. You site your reason for moving it is to put it close to the sources, well, traditionally BSD sources are layed out to match the installed DESTDIR tree. I understand things like csh and sh conf files moving, that makes since in a world where csh or sh may or may not be installed by a pkgbase, however that makes no since in a world where libc and hence master.passwd shall always be installed.

How many config files are now under libc and well always be installed? Could that not of been handled by make a etc pkg that is also installed with libc?

Suggested UPDATING entry:

Address @imp feedback

Update with right etc/Makefile changes

In D16785#357233, @will wrote:

Sorta weird to set an empty FILES=, perhaps bluetooth.device.conf should be moved first, so this file can be moved along with deleting the etc/defaults directory altogether.

In D16722#356962, @kib wrote:

In D16722#356907, @pfg wrote:

@rgrimes A lot of your questions would be resolved by reviewing how CONFS works in share/mk/bsd.confs.mk and its dependencies.

x86 kernels are linked at the fixed address and did not have relocations to be processed either by loader or by kernel itself until recently. With the introduction of ifuncs, there are relocations, but they can only be processed at the kernel bootstrap time since they require calls to the resolver functions, which expect the kernel environment.

In D16793#357232, @alc wrote:

In D16793#357204, @kib wrote:

In D16793#357203, @alc wrote:

Should I bump __FreeBSD_version?

I would not.

Could you please elaborate? This is going to impact out-of-tree drivers, e.g., Virtual Box and the newer drm, right? Are you suggesting that I never bump __FreeBSD_version, or wait until all of the kmem functions are "fixed"?

This looks good to me.

Sorta weird to set an empty FILES=, perhaps bluetooth.device.conf should be moved first, so this file can be moved along with deleting the etc/defaults directory altogether.

In D16793#357204, @kib wrote:

In D16793#357203, @alc wrote:

Should I bump __FreeBSD_version?

I would not.

I should have mentioned that I did look at 'readelf -r' output of the kernel on Michael's box previously and I think it only included a few R_PPC_ADDR32, but they weren't for the relevant section. The rest of the relocations were all R_PPC_RELATIVE which the existing code already handled.

Do we re-process relocations during kernel startup? If so, that explains why kldload worked after boot without this change. However, if so, do we have any kind of policy on which relocations the loader should do? For example, should it really limit itself to a subset to since the kernel will do them all again anyway?

• Move mips64el routines to a dedicated file.

In D16793#357203, @alc wrote:

Should I bump __FreeBSD_version?

In D16793#357198, @kib wrote:

kmem_malloc() needs sys_machdep.c update. I think it is better to keep them in separate changes.

kmem_malloc() needs sys_machdep.c update. I think it is better to keep them in separate changes.

I'm happy to either add kmem_malloc() and kmem_alloc_contig() to this patch or do them separately.

This should probably include an increment to __FreeBSD_version.