Re: [PATCH v4 0/4] m68k: system call table generation support
Hi Geert,
On Sat, 27 Oct 2018 at 20:17, Geert Uytterhoeven wrote:
>
> Hi Firoz,
>
> On Fri, Oct 26, 2018 at 7:06 AM Firoz Khan wrote:
> > The purpose of this patch series is, we can easily add/modify/delete
> > system call table support by changing entry in syscall.tbl file
> > instead of manually changing many files. The other goal is to unify
> > the system call table generation support implementation across all
> > the architectures.
> >
> > The system call tables are in different format in all architecture.
> > It will be difficult to manually add, modify or delete the system
> > calls in the respective files manually. To make it easy by keeping
> > a script and which'll generate uapi header file and syscall table
> > file.
> >
> > syscall.tbl contains the list of available system calls along with
> > system call number and corresponding entry point. Add a new system
> > call in this architecture will be possible by adding new entry in
> > the syscall.tbl file.
> >
> > Adding a new table entry consisting of:
> > - System call number.
> > - ABI.
> > - System call name.
> > - Entry point name.
> >
> > ARM, s390 and x86 architecuture does exist the similar support. I
> > leverage their implementation to come up with a generic solution.
> >
> > I have done the same support for work for alpha, ia64, microblaze,
> > mips, parisc, powerpc, sh, sparc, and xtensa. Below mentioned git
> > repository contains more details.
> > Git repo:- https://github.com/frzkhn/system_call_table_generator/
> >
> > Finally, this is the ground work to solve the Y2038 issue. We need
> > to add two dozen of system calls to solve Y2038 issue. So this patch
> > series will help to add new system calls easily by adding new entry
> > in the syscall.tbl.
>
> Thanks for the update!
>
> Can you please tell the audience what has been changed in v4?
Sure.
- I added the comments in syscall.tbl and solved mixed (space and tab)
indentation.
- Modified the scripts (syscalltbl.sh and syscallhdr.sh) as per the feedback
provided by Arnd, Finn Thain, Eugene Syromiatnikov and Rolf Eike Beer.
Eg:-
- echo options are not portable; changed to printf
- "let" is a bash extension; changed posix-conformant expression.
- Finally I optimized the script and solved mixed indentation.
>
> When posting a new version of a patch or patch series, it is a good
> idea to include a changelog in the cover letter and/or patches.
Sure, will do!
Thanks
Firoz
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-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
[git pull] m68knommu fix for v4.20
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change to fix an out of bounds array access when parsing boot command line. Regards Greg The following changes since commit 35a7f35ad1b150ddf59a41dcac7b2fa32982be0e: Linux 4.19-rc8 (2018-10-15 07:20:24 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to 381fdd62c38344a771aed06adaf14aae65c47454: m68k: fix command-line parsing when passed from u-boot (2018-10-16 09:46:02 +1000) Angelo Dureghello (1): m68k: fix command-line parsing when passed from u-boot arch/m68k/kernel/uboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: m68k using deprecated internal APIs?
Hi Arnd, On 28/10/18 1:54 am, Arnd Bergmann wrote: On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven wrote: Hi Arnd, 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. This is also missing on a couple of others (ia64 at least, not sure what else). Another one would be having CLKDEV_LOOKUP without COMMON_CLK. This one is not a problem for m68k but is for a couple of ARM and MIPS platforms that have not yet been converted to COMMON_CLK. There are probably a couple more like this. I don't actually see any that are /only/ used by m68k, but there are some interfaces that would be good to stop using overall to keep things simpler. I have been working on and maintaining parts of m68k for a long time, and I was not aware that there was a number of problem areas that are causing real pain. Maybe a friendly email from subsystem maintainers that see issues would go a long way. At least if the m68k (and other arch) communities know they can work toward solutions sooner rather than later. Talk of ultimatums seems a bit heavy handed when only one side seems to be aware there is a problem. Regards Greg
Re: m68k using deprecated internal APIs?
On Sun, 28 Oct 2018, Geert Uytterhoeven wrote: > > > > > > 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. > Certain arm and m68k platforms select ARCH_USES_GETTIMEOFFSET (hence these architectures have "TODO" in features/time/modern-timekeeping). Moreover, it seems that we need both features (!ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS) in order to get the benefit of simplification... > > 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! > I think it would be helpful if Documentation/features/... would state what kind of benefit warranted the TODO. E.g. a win-win simplification arises from replacing arch code with generic code. Another kind of simplification arises from removing special cases from core code. The !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS example seems to offer both kinds of benefit. > 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). > Perhaps we should ask, "which features, if implemented, would actually complicate things, taking us further from the goal?" In those cases, "TODO" seems to be bad advice. Perhaps "optional" would be better. --
[git pull] m68k updates for 4.20
Hi Linus,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
tags/m68k-for-v4.20-tag1
for you to fetch changes up to 58c116fb7dc6703a557fe79c6e6ebab1450082b3:
m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode (2018-08-31 09:30:42
+0200)
m68k updates for v4.20
- Just two small cleanups.
Thanks for pulling!
P.S. Sorry for the late pull request.
I didn't bring my NitroKey to Edinburgh, and had moved all other
secret keys offline, as recommended.
Robert P. J. Day (1):
m68k/atari: ARAnyM - Remove reference to long-deprecated MODULE_PARM
Руслан Исаев (1):
m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode
arch/m68k/emu/nfeth.c| 4
arch/m68k/kernel/sun3-head.S | 6 --
2 files changed, 10 deletions(-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-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
Re: m68k using deprecated internal APIs?
[ 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 wrote:
> On Sat, 27 Oct 2018, Arnd Bergmann wrote:
> > On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven
> > 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 -- ge...@linux-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
Re: m68k using deprecated internal APIs?
On Sat, 27 Oct 2018, Arnd Bergmann wrote: > On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven > wrote: > > > > Hi Arnd, > > > > 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 (?) > This is also missing on a couple of others (ia64 at least, not sure what > else). Another one would be having CLKDEV_LOOKUP without COMMON_CLK. > This one is not a problem for m68k but is for a couple of ARM and MIPS > platforms that have not yet been converted to COMMON_CLK. > > There are probably a couple more like this. I don't actually see any > that are /only/ used by m68k, but there are some interfaces that would > be good to stop using overall to keep things simpler. > 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)? 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. -- >Arnd >
