From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F4D9C433B4 for ; Wed, 7 Apr 2021 07:46:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33B52613AF for ; Wed, 7 Apr 2021 07:46:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244876AbhDGHqd (ORCPT ); Wed, 7 Apr 2021 03:46:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:38080 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240787AbhDGHqa (ORCPT ); Wed, 7 Apr 2021 03:46:30 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 506F26139B; Wed, 7 Apr 2021 07:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617781581; bh=xFlb8XuCVKFs7yVEDsdkMeg3jdfQxp2CndWAV0U162E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ORVDJjqJEXVocI7AShlkTTGMHVgJqicsVwmudrbkIDeG4Fh8LOtzm931wbly02wsZ VaozEwnhlPONZTjFGAIbLCDedC4ilE3zRir+XMVUrLqkVDFt+lpApFHdoy+9e3MRay cIviO2Gbnx3GEKnikUyoqftydQXuqtgxgNjBPZOo= Date: Wed, 7 Apr 2021 09:46:18 +0200 From: Greg Kroah-Hartman To: Geert Uytterhoeven Cc: Masahiro Yamada , Michal Marek , linux-kbuild , Linux-Arch , Linux Kernel Mailing List , "David S. Miller" , "James E.J. Bottomley" , Albert Ou , Borislav Petkov , Catalin Marinas , Christian Borntraeger , Greentime Hu , Heiko Carstens , Helge Deller , Ingo Molnar , Ley Foon Tan , Michael Ellerman , Nick Hu , Palmer Dabbelt , Paul Walmsley , Rich Felker , Russell King , Thomas Gleixner , Vasily Gorbik , Vincent Chen , Will Deacon , Yoshinori Sato , the arch/x86 maintainers Subject: Re: [PATCH 00/20] kbuild: unify the install.sh script usage Message-ID: References: <20210407053419.449796-1-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Wed, Apr 07, 2021 at 09:18:11AM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > Thanks for your series! > > On Wed, Apr 7, 2021 at 7:34 AM Greg Kroah-Hartman > wrote: > > Almost every architecture has copied the "install.sh" script that > > originally came with i386, and modified it in very tiny ways. This > > patch series unifies all of these scripts into one single script to > > allow people to understand how to correctly install a kernel, and fixes > > up some issues regarding trying to install a kernel to a path with > > spaces in it. > > > > Note that not all architectures actually seem to have any type of way to > > install a kernel, they must rely on external scripts or tools which > > feels odd as everything should be included here in the main repository. > > I'll work on trying to figure out the missing architecture issues > > afterward. > > I'll bite ;-) > > Does anyone actually use these scripts (outside of x86)? I think so, if not then what do they use? Ok, I'll answer that, Before this week, I used my own script, a horrible hack I've drug along for years: https://github.com/gregkh/gregkh-linux/blob/master/scripts/install but for almost everyone else, they just use /sbin/installkernel that is provided by their distro. But this feels really odd given that we should include the logic to install the kernel in the kernel source itself, otherwise everyone has to rely on an external package that no one knows where it is. > I assume the architectures that have them, only have them because they > were copied from x86 while doing the initial ports ("oh, a file I don't > have to modify at all."). > But installing the kernel can be very platform-specific. > Do you need the vmlinux, vmlinux.gz, Image, zImage, uImage, ...? > With separate or appended DTB? That seems handled already by the arch/ARCH/boot/Makefile logic today, so I do not think we need to change that. > Even on x86, the script will bail out with "Cannot find LILO." if you're > using Grub. The last change in this series tries to "soften" that language so that isn't really an issue anymore. I want to turn this into something that everyone can use, so we do not have to rely on distro-specific or other external programs, as trying to explain how to install a kernel to someone new to kernel development is a real pain. > Anyway, having less of them is good. Agreed, thanks for the review :) greg k-h