Re: HEADSUP: drm-current-kmod now installs sources

On Wed, 2019-08-14 at 09:08 -0700, John Baldwin wrote:
> On 8/13/19 3:17 PM, Ian Lepore wrote:
> > On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote:
> > > For developers this means even if you are doing testing on a box
> > > that doesn't use DRM, you can install the package so that kernel
> > > builds will try to compile it and hopefully spot KPI/KBI changes
> > > before they land in the tree so that the port/package can be
> > > patched in tandem with committing changes to HEAD.  Note that
> > > even
> > > builds of work trees in git checkouts, etc. will find the DRM
> > > modules and try to build them if the package is installed.
> > 
> > That last sentence sounds ominous.  Are you saying that when I'm on
> > my
> > amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6
> > it's going to find /usr/local/sys/modules/drm-current-kmod and try
> > to
> > crossbuild it for armv6?
> 
> Yes, meaning that you _can_ cross-build a DRM kernel module.  This
> also means
> that if you are trying out a KPI change and have the package
> installed, make
> tinderbox will now catch a change that breaks the DRM drivers on only
> a subset
> of platforms (e.g. a powerpc or arm-only breakage that currently goes
> unnoticed when a developer is only doing build testing from an amd64
> host).
> 
> There are several ways you can disable this either globally or in
> more
> fine-grained ways:
> 
> 1) You can set LOCALBASE to a different path either in a kernel
> config
>    (via makeoptions) or when invoking buildkernel.
> 
>    For example, I mount my rpi's sdcard at /mnt on my amd64 laptop
> and
>    then cross-build into it, so I could set LOCALBASE to
> /mnt/usr/local when
>    building the rpi's kernel to honor any kmod packages installed on
> the rpi.
> 
> 2) You can set LOCAL_MODULES (makeoptions, command line) to a list of
> modules
>    to build (empty disables building any of them).
> 
> 3) You could set LOCAL_MODULES in /etc/src.conf to affect all kernel
> builds.
>    (You probably don't want to set LOCALBASE there as it probably
> affects
>    other things.)
> 
> 4) You can build the port with the SOURCES option disabled if you
> want to
>    never build modules for a specific port.
> 
> > How about when I'm doing a build of 11-stable for testing, but
> > what's
> > in my /usr/local is sources for a 13-current driver?
> 
> Given that the kmod's are supposed to be portable across branches,
> the build really shouldn't be breaking.  But the same ability is
> still
> there to as above to disable builds either in general or for
> specific kernel configs or buildkernel invocations.
> 

This all sounds vaguely wrong, backwards, to me.  A developer who is
using a given module on their build system might want that module to be
rebuilt automatically, but only if the build parameters match those of
the running build host system.

If my build host is running freebsd 12 amd64 and I'm doing a build for
freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64
driver module for a different OS arch and version just because that
module happens to be installed on the system I use to do crossbuilds.

My objections are theoretical... this automation just seems improperly
designed to me.  But it won't actually affect me in any way, because I
don't build video driver modules from ports, and I don't run freebsd
current on my build host machine.  Probably the number of people doing
crossbuilding is small enough that nobody else is going to object to
this "the whole world is amd64" automation.

-- Ian