On Wed, Feb 01, 2023 at 02:22:07PM +0100, Thorsten Leemhuis wrote: > On 01.02.23 13:44, Greg KH wrote: > > On Wed, Feb 01, 2023 at 01:42:29PM +0100, Greg KH wrote: > >> On Wed, Feb 01, 2023 at 12:52:30PM +0100, Thorsten Leemhuis wrote: > >>> Add a text explaining how to quickly build a kernel, as that's something > >>> users will often have to do when they want to report an issue or test > >>> proposed fixes. This is a huge and frightening task for quite a few > >>> users these days, as many rely on pre-compiled kernels and have never > >>> built their own. They find help on quite a few websites explaining the > >>> process in various ways, but those howtos often omit important details > >>> or make things too hard for the 'quickly build just for testing' case > >>> that 'localmodconfig' is really useful for. Hence give users something > >>> at hand to guide them, as that makes it easier for them to help with > >>> testing, debugging, and fixing the kernel. > >> > >> First off, this is great, thanks for doing this. > > Thx, feels good to hear. > > Bisection is next on my todo list once this matured... > > >> One minor comment, to prevent people from "overloading" the > >> git.kernel.org systems: > >> > >>> +.. _sources_sbs: > >>> + > >>> + * Retrieve the sources of the Linux version you intend to build; then change > >>> + into the directory holding them, as all further commands in this guide are > >>> + meant to be executed from there. > >>> + > >>> + If you plan to only build one particular kernel version, download its source > >>> + archive from https://kernel.org; afterwards extract its content to '~/linux/' > >>> + and change into the directory created during extraction. > >>> + > >>> + In most other situations your best choice is to fetch the sources using git:: > >>> + > >>> + git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git \ > >>> + ~/linux/sources > >>> + cd ~/linux/sources/ > >> > >> Ideally you should never do a "full clone from scratch" like this, as it > >> takes up loads of server resources. The "best" way to do this is to > >> download the kernel git bundle, and then pull and resolve the remaining > >> bits. It's explained, with a script to do the work for you, here: > >> > >> https://kernel.org/best-way-to-do-linux-clones-for-your-ci.html > > > > Oops, here's the full steps involved: > > https://www.kernel.org/cloning-linux-from-a-bundle.html > > the first link above has a script that does it all for you, but you > > probably just want to copy the steps at this last link instead. > > Great idea, thx for bringing this up -- now that you mention it, I > remember those pages and the script again... :-/ > > Sadly my "after cloning Linus tree, add the stable tree as remote and > fetch everything" approach would will still create a lot of load. Not really, nothing like doing a "full" clone of the original repo. It's a much smaller working set that needs to be handled that way on the server side. I do this (as do many others) for CI systems, and the primary workload is on the client resolving the bundle, that can take a bit of time, but that's all client side, not server. > I > could use the script with the stable git repo, as that includes > mainline; but I noticed it sometimes is not fully up2date. At least I > once noticed it was quite a few hours (or maybe even a day?) behind. Is > that normal? I assume you should know. I think it's generated daily, so yes, it will be a bit out of date, but that's fine. > Anyway: maybe "a little bit behind" isn't something that's much of a > problem for this document. Adding the remote and doing a pull is good and recommended, so it's fine if it's a day or so out of date. thanks, greg k-h
