From: Ingo Molnar <mingo@elte•hu>
To: Valdis.Kletnieks@vt•edu
Cc: "Eric W. Biederman" <ebiederm@xmission•com>,
James Bottomley <James.Bottomley@HansenPartnership•com>,
Linus Torvalds <torvalds@linux-foundation•org>,
linux-kernel@vger•kernel.org,
Linux Containers <containers@lists•osdl.org>,
netdev@vger•kernel.org, Geert Uytterhoeven <geert@linux-m68k•org>
Subject: Re: [GIT PULL] Namespace file descriptors for 2.6.40
Date: Wed, 25 May 2011 10:25:14 +0200 [thread overview]
Message-ID: <20110525082514.GE21552@elte.hu> (raw)
In-Reply-To: <4508.1306283693@localhost>
* Valdis.Kletnieks@vt•edu <Valdis.Kletnieks@vt•edu> wrote:
> On Tue, 24 May 2011 09:16:28 +0200, Ingo Molnar said:
> > * Eric W. Biederman <ebiederm@xmission•com> wrote:
> > > 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
next prev parent reply other threads:[~2011-05-25 8:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-21 23:39 [GIT PULL] Namespace file descriptors for 2.6.40 Eric W. Biederman
2011-05-21 23:42 ` Linus Torvalds
2011-05-22 0:33 ` Eric W. Biederman
[not found] ` <m1boyvpo9r.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2011-05-22 7:13 ` James Bottomley
2011-05-22 8:42 ` Ingo Molnar
2011-05-24 7:03 ` Eric W. Biederman
2011-05-24 7:16 ` Ingo Molnar
2011-05-25 0:34 ` Valdis.Kletnieks
2011-05-25 8:25 ` Ingo Molnar [this message]
2011-05-25 8:35 ` Geert Uytterhoeven
2011-05-25 12:47 ` Ingo Molnar
2011-05-25 13:00 ` Geert Uytterhoeven
2011-05-25 13:17 ` Ingo Molnar
2011-05-25 15:22 ` Geert Uytterhoeven
2011-05-24 7:26 ` James Bottomley
2011-05-24 8:11 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2011-05-23 21:05 Eric W. Biederman
2011-05-25 21:05 ` C Anthony Risinger
2011-05-25 21:38 ` Serge E. Hallyn
2011-05-25 21:55 ` C Anthony Risinger
2011-05-25 22:11 ` Michał Mirosław
2011-05-25 23:40 ` Eric W. Biederman
2011-05-27 20:18 ` C Anthony Risinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110525082514.GE21552@elte.hu \
--to=mingo@elte$(echo .)hu \
--cc=James.Bottomley@HansenPartnership$(echo .)com \
--cc=Valdis.Kletnieks@vt$(echo .)edu \
--cc=containers@lists$(echo .)osdl.org \
--cc=ebiederm@xmission$(echo .)com \
--cc=geert@linux-m68k$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=torvalds@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox