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]
Message-ID: <ee51e10d-0fbf-d87f-aa98-a95d97a7e437@canonical.com>
Date:   Tue, 2 Nov 2021 15:55:26 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Russell King <linux@...linux.org.uk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" 
        <linux-samsung-soc@...r.kernel.org>,
        Olof Johansson <olof@...om.net>, Kukjin Kim <kgene@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Sylwester Nawrocki <snawrocki@...nel.org>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Inki Dae <inki.dae@...sung.com>, Cedric Roux <sed@...e.fr>,
        Sam Van Den Berge <sam.van.den.berge@...enet.be>,
        Lihua Yao <ylhuajnu@...look.com>,
        Heiko Stuebner <heiko@...ech.de>
Subject: Re: [RFC PATCH] ARM: s3c: mark as deprecated and schedule removal
 after 2022

On 02/11/2021 14:05, Arnd Bergmann wrote:
> On Tue, Nov 2, 2021 at 12:05 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@...onical.com> wrote:
>>
>> The Samsung S3C24xx and S3C64xx platforms are very old designs. S3C2416
>> was introduced in 2008 and S3C6410 in 2009/2010.  They are not widely
>> available anymore - out-of-stock on FriendlyArm (one of manufacturers of
>> boards) and only few specialist stores still offer them for quite a high
>> price.
>>
>> The community around these platforms was not very active, so I suspect
>> no one really uses them anymore. Maintenance takes precious time so
>> there is little sense in keeping them alive if there are no real users.
>>
>> Let's mark all S3C24xx and S3C64xx platforms as deprecated and mention
>> possible removal in one year (after 2022).  The deprecation message will
>> be as text in Kconfig, build message (not a warning though) and runtime
>> print error.
>>
>> If there are any users, they might respond and postpone the removal.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
> 
> Looks good to me.
> 
> We have a couple of platforms that are in a similar state, and we could do
> the same there. I'd have to dig through
> https://lore.kernel.org/linux-arm-kernel/CAK8P3a2VW8T+yYUG1pn1yR-5eU4jJXe1+M_ot6DAvfr2KyXCzQ@mail.gmail.com/
> to see which ones promised to get back to working on the code and
> ended up not doing so. ;-)
> 
> The ones that would help the most in removing are probably omap1,
> pxa, and the strongarm-based platforms: those have a lot of special
> cases in the code base. At least a year ago the maintainers wanted
> to keep those around, but maybe the 2022 LTS kernel is a better
> time for planned EOL.

If the maintainers or users expressed wish to keep them alive, let's
keep them. In fact there might be some industrial machine working for 20
more years...

If you did not receive any feedback about your queries, I am happy to
add similar deprecation-warning notes to these as well. Just let me know
which one should be affected.

> I also still have a backlog of cleanup patches
> for omap1 and pxa (similar to the s3c24xx changes I did) that we
> should get mainlined if we want to keep them around after all.
> 
> At some point later we can also seriously look into removing all
> non-DT machine support, which would impact all of these:
> 
> $ git grep -w MACHINE_START arch/arm/mach-* | cut -f 3 -d/ | uniq -c
>       1 mach-cns3xxx
>      12 mach-davinci
>       2 mach-dove
>      19 mach-ep93xx
>       3 mach-footbridge
>       6 mach-iop32x
>       2 mach-ixp4xx
>      10 mach-mmp
>       3 mach-mv78xx0
>      14 mach-omap1
>      17 mach-orion5x
>      62 mach-pxa
>       1 mach-rpc
>      36 mach-s3c
>      13 mach-sa1100
> 
>> +#pragma message "The platform is deprecated and scheduled in removal (see platform help). " \
>> +               "Please reach to the maintainers of the platform " \
>> +               "and linux-samsung-soc@...r.kernel.org if you still use it." \
>> +               "Without such feedback, the platform will be removed after 2022."
>> diff --git a/arch/arm/mach-s3c/s3c64xx.c b/arch/arm/mach-s3c/s3c64xx.c
>> index 4dfb648142f2..3e248f0e96a2 100644
>> --- a/arch/arm/mach-s3c/s3c64xx.c
>> +++ b/arch/arm/mach-s3c/s3c64xx.c
>> @@ -425,3 +425,8 @@ static int __init s3c64xx_init_irq_eint(void)
>>         return 0;
>>  }
>>  arch_initcall(s3c64xx_init_irq_eint);
>> +
>> +#pragma message "The platform is deprecated and scheduled in removal (see platform help). " \
>> +               "Please reach to the maintainers of the platform " \
>> +               "and linux-samsung-soc@...r.kernel.org if you still use it." \
>> +               "Without such feedback, the platform will be removed after 2022."
> 
> I don't want these to clutter up my randconfig build output, which I keep
> completely empty by default. If you add an
> 
> #ifndef CONFIG_COMPILE_TEST
> 
> check around them, I'm fine with it though -- it would still catch all
> real users
> without bothering build-testing bots.

I like that idea, I'll use it in v2. No one really should build a real
config with COMPILE_TEST and I want to nag and find the real users.

> I think even with CONFIG_WERROR, we don't fail the build for #warning,
> so that would also work in place of #pragma message.

It fails, I tried it. That's why #pragma.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ