Bug#820260: nvidia-kernel-source: Module does not build with make-kpkg (kernel-package)

[Kevin Locke]

Hi Andreas,

Thanks for the detailed explanation.  It helps a lot, although I must 
confess that I am not especially familiar with Kbuild or conftest so 
please forgive what may be stupid questions below.

On 04/08/2016 06:58 AM, Andreas Beckmann wrote:
> On 2016-04-08 03:04, Kevin Locke wrote:
>> Perhaps the rationale for removing support for KSRC can shed some light
>> on the tradeoffs for this fix vs reverting the commit.
>
> passing KSRC=/lib/modules/KVERS/build (as done by m-a) does not work for
> the "split" header packages shipped in Debian. There is
> /lib/modules/KVERS/source, too, and it is *different* from .../build .
> So we would have to pass SYSSRC and SYSOUT to the NVIDIA build system -
> or just KERNEL_UNAME (and let the build system figure out the correct
> paths).
> Of course that broke your case (unified, but not installed, kernel
> source) I've tried something in branches/304 that seems to work ...

Ah, is that r6371?[1]  If I understand correctly, when KSRC starts with 
/lib/modules/$(KVERS) KERNEL_UNAME=$KVERS is passed instead of KSRC to 
allow the appropriate source directory to be be deduced from the kernel 
version.   Otherwise KSRC is passed as SYSSRC.  Is that correct?

> That KVERS alone is not working seems to be specific to the NVIDIA
> kernel module - and their assumptions about kernel source layout in
> their conftest.sh script (instead of leaving such details totally to
> Kbuild). But I'm much happier now that we can use conftest.sh directly
> and we no longer have to maintain our custom conftest.h that substituted
> conftest.sh

Gotcha.  Good to see the advantages.  Sounds like a nice improvement.

> What's likely not going to get working is the dkms build with
> non-installed kernel headers (i.e. not available via
> /lib/modules/KVERS/{build,source})

That's a bummer.  Is that because dkms passes KSRC outside of 
/lib/modules which is not suitable for use as SYSSRC, or something else?

If I understand correctly, it seems like the root of the issue is that 
KSRC is unreliable because it sometimes refers to the unified sources 
and sometimes refers to the arch-specific build headers.  Is there any 
chance the debian kernel build tools could agree on an additional 
variable which refers to the common headers?  That way KSRC could be 
used unconditionally as SYSOUT and KSRCCOMMON (or whatever) as SYSSRC. 
Or, at least, the two variables could be compared to determine if the 
sources are unified.  Have I understood incorrectly, or is that 
infeasible (politically or otherwise)?

Thanks again,
Kevin

1.  https://anonscm.debian.org/viewvc/pkg-nvidia?view=revision&revision=6371