Re: m68k using deprecated internal APIs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[ Wow, I hadn't expected such a heated discussion, I just wanted to
know which code
  needed fixes... ]

On Sun, Oct 28, 2018 at 8:00 AM Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> wrote:
On Sat, 27 Oct 2018, Arnd Bergmann wrote:
On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
https://lwn.net/Articles/769468/ wrote:
 For example, the m68k architecture uses a number of internal APIs that no other
architecture needs at this point; removing that architecture would enable removing
the APIs as well

and

Ted Ts'o suggested that an ultimatum could be made: either the m68k architecture
stops using the old, deprecated timer API (for example) within one year or it is
removed from the kernel.

Which APIs are these exactly?

The example I gave was GENERIC_CLOCKEVENTS on m68, which is
supported on most but not all machines there.

That suggests that the removal of just those machines would suffice (as
opposed to the removal of the entire arch).

Also, Documentation/features/time/clockevents/arch-support.txt says,
    |        m68k: |  ok  |

These two observations make me wonder whether the clockevents feature is
related to the discussion quoted above (?)

GENERIC_CLOCKEVENTS is selected only for a few Coldfire CPU types.

Perhaps the most overdue features are the following. At least 50% of
architectures have already implemented these features (or else cannot
implement them).

$ grep -cw TODO Documentation/features/*/*/arch-support.txt |sort -t: -k2n |head -n 9
Documentation/features/time/clockevents/arch-support.txt:1
Documentation/features/time/modern-timekeeping/arch-support.txt:2
Documentation/features/vm/numa-memblock/arch-support.txt:2
Documentation/features/vm/THP/arch-support.txt:5
Documentation/features/sched/numa-balancing/arch-support.txt:6
Documentation/features/core/tracehook/arch-support.txt:7
Documentation/features/core/generic-idle-thread/arch-support.txt:8
Documentation/features/locking/lockdep/arch-support.txt:8
Documentation/features/debug/kgdb/arch-support.txt:12

Of those, m68k has a "TODO" against the following 5 features.

time/modern-timekeeping
core/tracehook
core/generic-idle-thread
locking/lockdep
debug/kgdb

The question is, which of those features, if implemented, would contribute
the most towards the goal (that is, to keep things simpler)?

That's a very good question!

E.g. kgdb is not a must-have, and lockdep matters much less if !SMP (and I don't
have RAM for storing all data it needs anyway).

We might also ask about features that cannot be implemented on m68k; there
are 4 of those.

$ grep -cw "m68k.*[.][.]" Documentation/features/*/*/arch-support.txt |sort -t: -k2n
...
Documentation/features/sched/numa-balancing/arch-support.txt:1
Documentation/features/vm/THP/arch-support.txt:1
Documentation/features/vm/TLB/arch-support.txt:1
Documentation/features/vm/numa-memblock/arch-support.txt:1

At least 8 out of 24 architectures would have to be deleted to make that
list any shorter.

I seriously doubt "impossible" features matter ;-)

BTW, I believe KPTI can be implemented, without a performance penalty,
unlike on x86...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux