Re: CVS commit: src

[Pierre Pronchery <khorben%defora.org@localhost>]

			Hi,

and thanks for the change - I have a few concerns though, as found below.

On 04/26/15 23:37, matthew green wrote:
> Module Name:	src
> Committed By:	mrg
> Date:		Sun Apr 26 21:37:22 UTC 2015
> 
> Modified Files:
> 	src/distrib/sets: mkvars.mk
> 	src/distrib/sets/lists/base: mi
> 	src/etc/mtree: NetBSD.dist.base
> 	src/share/mk: bsd.README bsd.own.mk
> 	src/sys/dev/microcode/radeon: Makefile
> 
> Log Message:
> two changes to radeon drm firmware:
> - only install it by default on x86, set new MKRADEONFIRMWARE variable
> - install in /libdata, so that separate /usr systems work

This will probably still fail on a system with the root filesystem
encrypted, as setup with cgdroot.kmod: /etc/rc from the ramdisk first
sets the "init.root" sysctl to the actual /, and only then init chroots
there and executes.

Even then the "hw.firmware.path" sysctl is relative to the ramdisk, so
unless its value is updated no firmware will be found on the system.
This could be done by cgdroot.kmod though, and I can write a patch for
this if it sounds good. But again, the firmware will not be found
initially...

> (this still doesn't solve PR#49811, which possibly could be handled by
> having them being a kernel module loaded by /boot.)

I think the problem is similar there. When booting with -a I guess
boot(8) will try to load modules from the same partition as the kernel
itself, which may not be the correct one (since -a is used).

Even worse is when booting Xen, as I don't think boot(8) is able to load
modules at all in this case; they are supported once the root filesystem
is mounted though.

From all of this I feel that the real fix will involve the ability to
load any firmware past init; config_mountroot(9) is not waiting long
enough for instance (same issue with iwm(4), which uses it).

To make things easier, I am writing this while running Xen with root
filesystem encryption :)

Cheers,
-- 
khorben