RE: [PATCH 0/3] x86 disk image and modules initramfs generation

["H. Peter Anvin" <hpa@zytor.com>]

Ok... not really sure how this relates to my patch. You are mentioned three separate things: modules, headers, and enough of the kernel machinery to build out of tree modules. The latter it normally done with a tree that corresponds to the state after build + "make clean"; which I *believe* is the same as after "make prepare". The former two are "make modules_install" and "make headers_install", respectively. Note you can direct them to directory hierarchies other than the local system ones for archiving.

It is simply not possible to provide a *general* solution that fits all distributions × all boot scenarios.

On April 20, 2021 1:30:07 AM PDT, David Laight <David.Laight@ACULAB.COM> wrote:
>From: H. Peter Anvin
>> Sent: 20 April 2021 00:03
>> 
>> When compiling on a different machine than the runtime target,
>> including but not limited to simulators, it is rather handy to be
>able
>> to produce a bootable image. The scripts for that in x86 are
>> relatively old, and assume a BIOS system.
>
>I've given up and copied the kernel tree onto all my test systems.
>
>I needed something like 'make modules_install' and 'make install'
>that would generated a directory tree that could be copied (scp -r)
>onto the target system.
>
>But the script to run 'update-grub' is all intwined in the commands.
>
>You also don't get a copy of the headers.
>Even for the local system (as root) you just get a symlink into
>the source tree.
>This causes a problem trying to build 'out of tree' modules
>after updating the kernel source tree (but not rebulding).
>
>I can (and do) write 'horrid' makefiles (gmake and nmake)
>but this seemed to need more refactoring that I wanted to do.
>
>	David
>
>-
>Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
>MK1 1PT, UK
>Registration No: 1397386 (Wales)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.