lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 7 Apr 2021 09:46:18 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        Linux-Arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Borislav Petkov <bp@...en8.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Greentime Hu <green.hu@...il.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Helge Deller <deller@....de>, Ingo Molnar <mingo@...hat.com>,
        Ley Foon Tan <ley.foon.tan@...el.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nick Hu <nickhu@...estech.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Rich Felker <dalias@...c.org>,
        Russell King <linux@...linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Vincent Chen <deanbo422@...il.com>,
        Will Deacon <will@...nel.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH 00/20] kbuild: unify the install.sh script usage

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
> <gregkh@...uxfoundation.org> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ