GNU bug report logs - #35110
[PATCH 0/3] Add support for loadable modules.

Previous Next

Full log

Message #32 received at 35110 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 35110 <at> debbugs.gnu.org
Subject: Re: [bug#35110] [PATCH 1/3] gnu: Add make-linux-module.
Date: Thu, 04 Apr 2019 09:48:34 +0200

Hi Danny,

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> On Wed, 03 Apr 2019 22:16:07 +0200
> Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> Would it make sense to turn it into a ‘linux-module-build-system’?  
>
> I started on it but haven't finished it yet.
>
>>That would avoid having to create a package object that cannot be built, just
>
> It can be built, it's just not very useful standalone because it only contains
> the source code and a few build artifacts (only the ones required to start
> building a module).  On the other hand it can be substituted and that's nice
> (if we can cut down the source code a lot, that is).

Can it be built (I’m talking about the ‘vhba-module’ package that you
sent)?  I’d expect it to look for the Linux makefile snippet and to fail
at that point, no?

> I don't understand how a build system would enable us to remove this step.
> (If it can, that's cool!)

We’d directly write:

  (define-public vhba-module
    (package
      (name "vhba-module")
      ;; …
      (build-system linux-module-build-system))

and that would abstract away the choice of dependencies (linux-libre,
kmod, GCC) and the set of build phases.

>> > +;; FIXME: Remove CONFIG_MODULE_SRCVERSION_ALL=y from our configs.  
>> 
>> What does that flag do?
>
> It adds a field "srcversion" to the ELF file of the module which is a hash of
> all the source files used to build it.
>
> Instead of removing it, we can also merge bug# 35111 instead and use that.
>
> Otherwise, the problem is that if CONFIG_MODULE_SRCVERSION_ALL is set and
> bug# 35111 not merged, one cannot build standalone modules because those
> would require the file "Module.symvers" of the completely built kernel
> to be available.
>
> Linux would also write a new file "Module.symvers" in the MODPOST step of
> the build of the module.

OK.  Sounds like we should merge #35111 then.

> For example, the lowest maintenance overhead would be to somehow have
> most of linux-libre's phases be injected into the module package and have
> both build in one build environment.  I.e. the module would have a package
> which would actually have phases 'unpack 'prepare-linux 'build 'check 'install
> where all the phases except for 'prepare-linux would be module-specific and
> 'prepare-linux would unpack the linux source and do everything just
> like the linux-libre package would have done, up until the 'build phase.
> It turned out that's too complicated to get to work for me for now.

What about factorizing these phases in a new (guix build
linux-module-build-system) module, which would export them as
‘%standard-phases’?  Then packages using ‘linux-module-build-system’
would use these phases by default, like we do for the other build
systems.

Does that make sense?

Thank you,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.