Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752579AbbHWLvT (ORCPT ); Sun, 23 Aug 2015 07:51:19 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:38440 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752160AbbHWLvR (ORCPT ); Sun, 23 Aug 2015 07:51:17 -0400 Date: Sun, 23 Aug 2015 13:51:13 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Brian Gerst , the arch/x86 maintainers , Linux Kernel Mailing List , "H. Peter Anvin" , Denys Vlasenko , Andy Lutomirski Subject: Re: [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct Message-ID: <20150823115113.GA26296@gmail.com> References: <1437354550-25858-1-git-send-email-brgerst@gmail.com> <1437354550-25858-5-git-send-email-brgerst@gmail.com> <20150721071151.GA8367@gmail.com> <20150805084826.GA23169@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1667 Lines: 45 * Linus Torvalds wrote: > On Wed, Aug 5, 2015 at 10:48 AM, Ingo Molnar wrote: > >> > >> Some of these field names are visible to userspace and can't change. > > > > That's a misconception: bits in the uapi headers can be renamed just fine. > > I disagree. If it causes pain for user space, we just shouldn't do it. Ok, agreed - I wanted to argue against the "can't change" statement and went overboard with my own statement ... Quite often headers can change and we've changed a number of fields in the past - but if they cause pain (as in this case) we don't do it. So I'd say that based on past experience: - changing small details in uapi headers is usually fine. - changing small details in the ABI is usually not fine. If anything breaks then the policy is the same, regardless of likelihood: reverting the change. > Some people copy the headers (preferred), others include the kernel header > directory with a include path or a symlink, and it's damn painful if we start > changing things that user space depends on. > > I'd say that it's like the ABI - if people don't really notice, you can do it, > but if it breaks the build of a user app, we should be very very careful. The > breakage is often hard to fix because of nasty versioning issues.. > > Our goal in life really is "don't screw up user space". Yeah, agreed 100%. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/