Re: Chicken and egg problem when building (third-party) kernel modules with <bsd.kmod.mk> -- how to solve?

From: John-Mark Gurney <jmg_at_funkthat.com>
Date: Wed, 11 Sep 2013 14:48:07 -0700
Lev Serebryakov wrote this message on Thu, Sep 12, 2013 at 01:17 +0400:
> Hello, John-Mark.
> You wrote 11 ???????????????? 2013 ??., 20:53:46:
> 
> >>  It is good idea to set KERNBUILDDIR when build module. But to set it you
> >> need to know ${.OBJDIR} from ${SYSDIR} and ${SYSDIR} is set in bsd.kmod.mk,
> >> which should be included last (after defining KERNBUILDDIR).
> >> 
> >>  How this loop could be broken?
> 
> JMG> If you need to build it stand alone, you still need the opt_*.h files
>  I'm speaking about making port with kernel module, but this port is using
> bsd.*.mk infrastructure by itself.
> 
> JMG> from the kernel you are going to run it with, and that directory is
> JMG> what you need to set KERNBUILDDIR...
>  KERNBUILDDIR could be set automagically with:
> 
> KERNBUILDROOT!= make -C ${SYSDIR} -V .OBJDIR
> KERNNAME!=              uname -i
> .if exists(${KERNBUILDROOT}/${KERNNAME}/opt_global.h) && !defined(KERNBUILDDIR)
> KERNBUILDDIR:=${KERNBUILDROOT}/${KERNNAME}
> .endif
> 
>   But here is problem, which I'm speaking about: it should go BEFORE
>  <bsd.kmod.mk> but it needs to use ${SYSDIR}.

After a brief discussion w/ imp, we have the idea of pulling this
information from the current running kernel.  It isn't hard to put
this information into an elf section and then extract it at module
build time...

For people releasing kernel modules for others, we'll need a better
way to handle this...

Plus, we might be able to identify a few macros that are KBI changing,
and finally get close to being able to prevent loading kernels that
would cause a crash due to KBI differences...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
Received on Wed Sep 11 2013 - 19:48:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:41 UTC