From: Valdis.Kletnieks@vt.edu
To: Kasper Dupont <kasperd@nhnxn.25.may.2011.kasperd.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: (Short?) merge window reminder
Date: Wed, 25 May 2011 16:48:29 -0400 [thread overview]
Message-ID: <24360.1306356509@localhost> (raw)
In-Reply-To: Your message of "Wed, 25 May 2011 14:26:18 +0200." <20110525122618.GA14303@colin.search.kasperd.net>
[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]
On Wed, 25 May 2011 14:26:18 +0200, Kasper Dupont said:
> On 24/05/11 21.13, Valdis.Kletnieks@vt.edu wrote:
> > Well, if we're looking at ELF-sized ABI changes, how about 3.0 be the
> > release where we re-sync the syscall numbers on all the archs? ;)
>
> If you want to do that I think the best way to do it is to
> have both the old and the new numbers co-exist through the
> 3.x series and the old ones go away in 4.0.
>
> You'd first have to find the highest number currently
> assigned and then add a bit of safety margin to decide on
> a starting point for the new numbers.
Most archs are sitting around 300-340. Alpha is the apparent
winner with 501. So start at 512 which is a nice round number.
> Or was it all a joke, and you don't actually want that
> cleanup to happen because of too much breakage?
Well, with 2.0, we had some ABI cratering due to ELF. I figured
*if* we're willing to do ABI cratering for a 3.0, cleaning up the
syscalls would be a nice drastic way to start. ;)
(Though to be honest, I think moving the a copy syscalls into one consistent
table starting at 512 or so for 3.0, and then nuking the low numbers for 4.0
would be better. We would however have to take into account architectures
that have limited number of syscalls available - any archs unable to handle
syscall numbers up to 1024?)
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2011-05-25 20:48 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-23 19:13 (Short?) merge window reminder Linus Torvalds
2011-05-23 19:20 ` Ingo Molnar
2011-05-23 20:33 ` Linus Torvalds
2011-05-23 20:52 ` Alexey Zaytsev
2011-05-25 14:12 ` Boaz Harrosh
2011-05-25 22:21 ` Tony Luck
2011-05-26 16:38 ` Boaz Harrosh
2011-05-27 5:44 ` Keith Curtis
2011-05-27 14:29 ` Zero bugs (was Re: (Short?) merge window reminder) Valdis.Kletnieks
2011-05-28 22:03 ` Florian Mickler
2011-06-01 23:49 ` Keith Curtis
2011-05-23 21:59 ` (Short?) merge window reminder Oliver Pinter
2011-05-23 22:21 ` Greg KH
2011-05-23 23:40 ` Matthew Wilcox
2011-05-23 23:10 ` jonsmirl
2011-05-23 23:17 ` Ted Ts'o
2011-05-23 23:21 ` Randy Dunlap
2011-05-23 23:23 ` H. Peter Anvin
2011-05-23 23:33 ` Linus Torvalds
2011-05-24 2:01 ` Ingo Molnar
2011-05-24 7:55 ` Arnd Bergmann
2011-05-24 12:15 ` Jan Engelhardt
2011-05-24 12:30 ` Jacek Luczak
2011-05-24 13:02 ` Jan Engelhardt
2011-05-24 13:18 ` Jacek Luczak
2011-05-24 14:43 ` Alan Cox
2011-05-24 15:07 ` jonsmirl
2011-05-24 17:36 ` H. Peter Anvin
2011-05-24 17:41 ` Linus Torvalds
2011-05-24 18:48 ` eschvoca
2011-05-24 21:05 ` Jan Engelhardt
2011-05-25 9:12 ` Emil Langrock
2011-05-26 16:13 ` Sérgio Basto
2011-05-24 15:46 ` Ralf Baechle
2011-05-24 17:29 ` Jan Engelhardt
2011-05-25 1:13 ` Valdis.Kletnieks
2011-05-25 12:26 ` Kasper Dupont
2011-05-25 20:48 ` Valdis.Kletnieks [this message]
2011-05-24 14:41 ` Alan Cox
2011-05-24 14:48 ` Ralf Baechle
2011-05-23 23:53 ` Phil Turmel
2011-05-24 2:11 ` Ingo Molnar
2011-05-24 18:06 ` Lisa Milne
2011-05-24 20:59 ` Zimny Lech
2011-05-25 15:03 ` Martin Nybo Andersen
2011-05-24 18:34 ` Matthias Schniedermeyer
2011-05-24 18:55 ` david
2011-05-24 21:25 ` Andy Lutomirski
2011-05-25 12:52 ` Jiri Kosina
2011-05-24 23:00 ` Hans-Peter Jansen
2011-05-23 19:22 ` Greg KH
2011-05-23 20:04 ` James Bottomley
2011-05-23 19:25 ` Thomas Gleixner
2011-05-23 20:21 ` Randy Dunlap
2011-05-23 21:02 ` Steven Rostedt
2011-05-24 19:06 ` Emil Langrock
2011-05-25 4:47 ` porpen
-- strict thread matches above, loose matches on Subject: below --
2011-05-24 13:40 werner
2011-05-24 14:09 ` Jerome Glisse
2011-05-24 15:35 Albert Pool
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=24360.1306356509@localhost \
--to=valdis.kletnieks@vt.edu \
--cc=kasperd@nhnxn.25.may.2011.kasperd.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).