On Tue, 24 May 2011 09:16:28 +0200, Ingo Molnar said:
* Eric W. Biederman [off-list ref] wrote:
quoted
My gut feel says we should really implement an
include/asm-generic/unistd-common.h to include all new system calls.
That way there would be only one file to touch instead of 50. Certainly it
works for include/asm-generic/unistd.h for the architectures that use it.
And all we really need is just a little abstraction on that concept.
I suppose that could be tried, although in practice it would probably be
somewhat complex due to the various compat syscall handling differences.
Can somebody fill us newcomers in on the arch-aeology of why some syscalls have
different numbers on different archs? I know it's partially because some simply
didn't implement some syscalls so there were numbering mismatches, but would it
have been *that* hard to wire all of those skipped syscalls up to one stub
'return -ENOSYS'?
On Tue, 24 May 2011 09:16:28 +0200, Ingo Molnar said:
quoted
* Eric W. Biederman [off-list ref] wrote:
quoted
My gut feel says we should really implement an
include/asm-generic/unistd-common.h to include all new system calls.
That way there would be only one file to touch instead of 50. Certainly it
works for include/asm-generic/unistd.h for the architectures that use it.
And all we really need is just a little abstraction on that concept.
I suppose that could be tried, although in practice it would probably be
somewhat complex due to the various compat syscall handling differences.
Can somebody fill us newcomers in on the arch-aeology of why some syscalls have
different numbers on different archs? I know it's partially because some simply
didn't implement some syscalls so there were numbering mismatches, but would it
have been *that* hard to wire all of those skipped syscalls up to one stub
'return -ENOSYS'?
It was done so for hysterical raisons mostly, and once a bad ABI is done it's
very hard to undo it: beyond pushing the 'good ABI' you'd also still have to
deal with the bad ABI for a decade or more.
So the background is that most architectures start out as quick concept
prototypes, doing:
cp -a arch/existingarch arch/newarch
where 'existingarch' used to be arch/i386/ in the early days. Now i386 had a
fair amount of x86 specific syscalls that were naturally removed from
'newarch'. Those created 'holes' in the numbers, which were then filled in with
new syscalls - a nice idea in itself!
Also sometimes 'newarch' did a 'clean', compressed list of syscall numbers
straight away, reordering syscalls. Once the 'quick prototype' hack starts
working on real hardware, once the syscall numbers get into the C library and
binutils it's very hard to ever transition away: you'd break the world!
An added source of noise that architectures tend to add new syscalls in a
different order: some are more interesting to them - some less.
So these syscall table hacks done very early during an arch's lifetime stick
around and create wild numbering noise in 20+ syscall tables:
[ slightly edited for readability ]
arch/alpha/include/asm/unistd.h: #define __NR_perf_event_open 493
arch/arm/include/asm/unistd.h: #define __NR_perf_event_open 364
arch/blackfin/include/asm/unistd.h: #define __NR_perf_event_open 369
arch/frv/include/asm/unistd.h: #define __NR_perf_event_open 336
arch/m68k/include/asm/unistd.h: #define __NR_perf_event_open 332
arch/microblaze/include/asm/unistd.h: #define __NR_perf_event_open 366
arch/mips/include/asm/unistd.h: #define __NR_perf_event_open 333
arch/mips/include/asm/unistd.h: #define __NR_perf_event_open 292
arch/mips/include/asm/unistd.h: #define __NR_perf_event_open 296
arch/mn10300/include/asm/unistd.h: #define __NR_perf_event_open 337
arch/parisc/include/asm/unistd.h: #define __NR_perf_event_open 318
arch/powerpc/include/asm/unistd.h: #define __NR_perf_event_open 319
arch/s390/include/asm/unistd.h: #define __NR_perf_event_open 331
arch/sh/include/asm/unistd_32.h: #define __NR_perf_event_open 336
arch/sh/include/asm/unistd_64.h: #define __NR_perf_event_open 364
arch/sparc/include/asm/unistd.h: #define __NR_perf_event_open 327
arch/x86/include/asm/unistd_32.h: #define __NR_perf_event_open 336
arch/x86/include/asm/unistd_64.h: #define __NR_perf_event_open 298
To fix this we'd create a new, clean offset defined by each architecture, and a
generic enumeration of new syscalls.
This would make it much easier to add new, generic syscalls to all
architectures indeed.
It would still leave compat syscall wrappers unaddressed though: those are
often numbered differently and sometimes need arch specific wrapper entry
functions, which then call the real generic syscall.
But at least the primary, 'native' syscall table of every arch could be kept
rather fresh via generic enumeration.
Thanks,
Ingo
On Wed, May 25, 2011 at 10:25, Ingo Molnar [off-list ref] wrote:
* Valdis.Kletnieks@vt.edu [off-list ref] wrote:
quoted
On Tue, 24 May 2011 09:16:28 +0200, Ingo Molnar said:
quoted
* Eric W. Biederman [off-list ref] wrote:
quoted
My gut feel says we should really implement an
include/asm-generic/unistd-common.h to include all new system calls.
That way there would be only one file to touch instead of 50. Certainly it
works for include/asm-generic/unistd.h for the architectures that use it.
And all we really need is just a little abstraction on that concept.
I suppose that could be tried, although in practice it would probably be
somewhat complex due to the various compat syscall handling differences.
Can somebody fill us newcomers in on the arch-aeology of why some syscalls have
different numbers on different archs? I know it's partially because some simply
didn't implement some syscalls so there were numbering mismatches, but would it
have been *that* hard to wire all of those skipped syscalls up to one stub
'return -ENOSYS'?
It was done so for hysterical raisons mostly, and once a bad ABI is done it's
very hard to undo it: beyond pushing the 'good ABI' you'd also still have to
deal with the bad ABI for a decade or more.
So the background is that most architectures start out as quick concept
prototypes, doing:
cp -a arch/existingarch arch/newarch
where 'existingarch' used to be arch/i386/ in the early days. Now i386 had a
fair amount of x86 specific syscalls that were naturally removed from
'newarch'. Those created 'holes' in the numbers, which were then filled in with
new syscalls - a nice idea in itself!
Also sometimes 'newarch' did a 'clean', compressed list of syscall numbers
straight away, reordering syscalls. Once the 'quick prototype' hack starts
working on real hardware, once the syscall numbers get into the C library and
binutils it's very hard to ever transition away: you'd break the world!
An added source of noise that architectures tend to add new syscalls in a
different order: some are more interesting to them - some less.
So these syscall table hacks done very early during an arch's lifetime stick
around and create wild numbering noise in 20+ syscall tables:
[ slightly edited for readability ]
arch/alpha/include/asm/unistd.h: #define __NR_perf_event_open 493
arch/arm/include/asm/unistd.h: #define __NR_perf_event_open 364
arch/blackfin/include/asm/unistd.h: #define __NR_perf_event_open 369
arch/frv/include/asm/unistd.h: #define __NR_perf_event_open 336
arch/m68k/include/asm/unistd.h: #define __NR_perf_event_open 332
arch/microblaze/include/asm/unistd.h: #define __NR_perf_event_open 366
arch/mips/include/asm/unistd.h: #define __NR_perf_event_open 333
arch/mips/include/asm/unistd.h: #define __NR_perf_event_open 292
arch/mips/include/asm/unistd.h: #define __NR_perf_event_open 296
arch/mn10300/include/asm/unistd.h: #define __NR_perf_event_open 337
arch/parisc/include/asm/unistd.h: #define __NR_perf_event_open 318
arch/powerpc/include/asm/unistd.h: #define __NR_perf_event_open 319
arch/s390/include/asm/unistd.h: #define __NR_perf_event_open 331
arch/sh/include/asm/unistd_32.h: #define __NR_perf_event_open 336
arch/sh/include/asm/unistd_64.h: #define __NR_perf_event_open 364
arch/sparc/include/asm/unistd.h: #define __NR_perf_event_open 327
arch/x86/include/asm/unistd_32.h: #define __NR_perf_event_open 336
arch/x86/include/asm/unistd_64.h: #define __NR_perf_event_open 298
To fix this we'd create a new, clean offset defined by each architecture, and a
generic enumeration of new syscalls.
This would make it much easier to add new, generic syscalls to all
architectures indeed.
It would still leave compat syscall wrappers unaddressed though: those are
often numbered differently and sometimes need arch specific wrapper entry
functions, which then call the real generic syscall.
But at least the primary, 'native' syscall table of every arch could be kept
rather fresh via generic enumeration.
So we can start all over at offset 501 (alpha just started using 500)
with a unified,
clean, and compressed list of syscalls? Or do we have some more other-os-compat
syscalls around in this range?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
But at least the primary, 'native' syscall table of every arch
could be kept rather fresh via generic enumeration.
So we can start all over at offset 501 (alpha just started using
500) with a unified, clean, and compressed list of syscalls? Or do
we have some more other-os-compat syscalls around in this range?
No, that would leave a big hole in the syscall table of most
architectures.
So what would be needed is for each architecture to define a 'generic
syscall table base index', ARCH_SYSCALL_BASE or so, and the generic
syscalls would be added for that.
Alpha would have 501, the others lower numbers.
The only general assumption we can rely on is that there's a range of
not yet used syscall numbers starting at the end of the current
syscall table.
Thanks,
Ingo
On Wed, May 25, 2011 at 14:47, Ingo Molnar [off-list ref] wrote:
* Geert Uytterhoeven [off-list ref] wrote:
quoted
quoted
But at least the primary, 'native' syscall table of every arch
could be kept rather fresh via generic enumeration.
So we can start all over at offset 501 (alpha just started using
500) with a unified, clean, and compressed list of syscalls? Or do
we have some more other-os-compat syscalls around in this range?
No, that would leave a big hole in the syscall table of most
architectures.
Sure, but we could (a) optimize for the case where the syscall number is
larger than 500 and/or (b) drop support for syscall numbers smaller than
501, depending on a config option.
So what would be needed is for each architecture to define a 'generic
syscall table base index', ARCH_SYSCALL_BASE or so, and the generic
syscalls would be added for that.
Alpha would have 501, the others lower numbers.
The only general assumption we can rely on is that there's a range of
not yet used syscall numbers starting at the end of the current
syscall table.
Yep, that would work too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
On Wed, May 25, 2011 at 14:47, Ingo Molnar [off-list ref] wrote:
quoted
* Geert Uytterhoeven [off-list ref] wrote:
quoted
quoted
But at least the primary, 'native' syscall table of every arch
could be kept rather fresh via generic enumeration.
So we can start all over at offset 501 (alpha just started using
500) with a unified, clean, and compressed list of syscalls? Or do
we have some more other-os-compat syscalls around in this range?
No, that would leave a big hole in the syscall table of most
architectures.
Sure, but we could (a) optimize for the case where the syscall number is
larger than 500 and/or (b) drop support for syscall numbers smaller than
501, depending on a config option.
Dunno why there is so much desire to complicate and break
well-working ABIs while we have a 14+ MLOC kernel with so much code
in it that is in dire need to be improved! :-)
Yes, we can reduce the syscall addition pain via the
ARCH_SYSCALLS_BASE trick, but we should really forget about
*removing* (or reordering) syscall numbers as the advantages are
marginal at best while the disadvantages are huge.
Messy syscall tables are irreversibly ingrained in tens of millions
of systems and there's nothing we can do about that. We can improve
the future shape of syscall tables and we can try not to make new
mistakes, and that's a large enough job in itself ;-)
Thanks,
Ingo
On Wed, May 25, 2011 at 15:17, Ingo Molnar [off-list ref] wrote:
* Geert Uytterhoeven [off-list ref] wrote:
quoted
On Wed, May 25, 2011 at 14:47, Ingo Molnar [off-list ref] wrote:
quoted
* Geert Uytterhoeven [off-list ref] wrote:
quoted
quoted
But at least the primary, 'native' syscall table of every arch
could be kept rather fresh via generic enumeration.
So we can start all over at offset 501 (alpha just started using
500) with a unified, clean, and compressed list of syscalls? Or do
we have some more other-os-compat syscalls around in this range?
No, that would leave a big hole in the syscall table of most
architectures.
Sure, but we could (a) optimize for the case where the syscall number is
larger than 500 and/or (b) drop support for syscall numbers smaller than
501, depending on a config option.
Dunno why there is so much desire to complicate and break
well-working ABIs while we have a 14+ MLOC kernel with so much code
in it that is in dire need to be improved! :-)
Because we (think we) need less active brain cells to write emails that to code.
So when we're not "active" enough to hack, we tend to respond to long winding
getting off-topic email threads...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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