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:   Tue, 2 Jun 2020 13:04:33 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support

Hi Adrian,

On Tue, Jun 2, 2020 at 12:41 PM John Paul Adrian Glaubitz
<glaubitz@...sik.fu-berlin.de> wrote:
> On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz wrote:
> >> These #ifdefs are relics from APUS (Amiga Power-Up System), which
> >> added a PPC board.  APUS support was killed off a long time ago,
> >> when arch/ppc/ was still king, but these #ifdefs were missed, because
> >> they didn't test for CONFIG_APUS.
> >
> > Reported-by: Al Viro <viro@...iv.linux.org.uk>
> > Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
> > ---
> >  drivers/video/fbdev/amifb.c |   63 --------------------------------------------
> >  1 file changed, 63 deletions(-)
>
> What do you mean with the sentence "when arch/ppc/ was still king"?

Ah, Bartl copied that from my email ;-)

There used to be APUS support under arch/ppc/.
Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\
architecture port under arch/powerpc/, and the old ones were dropped.
APUS was never converted, and thus dropped.

> Does that mean - in the case we would re-add APUS support in the future, that
> these particular changes would not be necessary?

They would still be necessary, as PowerPC doesn't grok m68k instructions.
Alternatively, we could just drop the m68k inline asm, and retain the C
version instead?  I have no idea how big of a difference that would make
on m68k, using a more modern compiler than when the code was written
originally.

Note that all of this is used only for cursor handling, which I doubt is
actually used by any user space application. The only exception is the
DIVUL() macro, which is used once during initialization, thus also not
performance critical.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ