linux-kernel - Re: (Short?) merge window reminder

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <24360.1306356509@localhost>
Date:	Wed, 25 May 2011 16:48:29 -0400
From:	Valdis.Kletnieks@...edu
To:	Kasper Dupont <kasperd@...xn.25.may.2011.kasperd.net>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: (Short?) merge window reminder

On Wed, 25 May 2011 14:26:18 +0200, Kasper Dupont said:
> On 24/05/11 21.13, Valdis.Kletnieks@...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?)

Content of type "application/pgp-signature" skipped