linux-kernel - Re: [RFC PATCH v1 14/31] ARC: syscall support

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 13 Nov 2012 10:37:43 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	"Gilad Ben-Yossef" <gilad@...yossef.com>
Cc:	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	tglx@...utronix.de
Subject: Re: [RFC PATCH v1 14/31] ARC: syscall support

On Tuesday 13 November 2012, Gilad Ben-Yossef wrote:
> So, I completely agree about not adding more deprecated system call or
> ABIs (thinking about the ptrace regset issues in another patch in the
> same patchset), but on the other hand I have to wonder if having a
> port in the tree that doesn't have a working C library or a debugger
> makes sense.
> 
> I mean, it is not quite the same thing as saying: "well, users of the
> old versions of the user tools will need to maintain out of tree
> patches". That makes sense - it puts the burden of maintenance on
> people clinging to new versions when newer one exists, but this is not
> what is happening with Arc. Right now, there are no working version of
> the tools for Arc, so everyone will need to use the out of tree
> patches.
> 
> I wonder what is worse - having an in tree port that no one (can) use
> or adding some deprecated crap (sorry...), clearly marked for deletion
> the minute a version of the relevant user tools exists that can be
> used with the new mechanisms?

The point is that all existing users already need to rebuild all their
user space since the upstream version is using the generic system call
numbers. What I want to avoid is breaking everything twice, and the most
logical point to do that is when moving from an out-of-tree kernel fork
to the mainline version.

If mainline doesn't work for you yet, the most logical choice is to
stay on whatever kernel you have working right now, and only change
over to the upstream version once it works with an ABI that we want
to maintain in the long term. Obviously I can't stop from using a
mix of the two while you are waiting for (or working on) getting
gdb and uclibc supported with the new interface, but my recommendation
is not to ship that in products to end-users that would suffer
from another ABI change later on. 

What I'm trying to enforce here is that the upstream version follows
the exact same rules that we apply to all other ports, which is
that we don't break existing user space that was running with an
older upstream kernel.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/