From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965209AbbFCRNy (ORCPT ); Wed, 3 Jun 2015 13:13:54 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:35908 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933287AbbFCRNh (ORCPT ); Wed, 3 Jun 2015 13:13:37 -0400 Date: Wed, 3 Jun 2015 19:13:32 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , Denys Vlasenko , Brian Gerst , Peter Zijlstra , Borislav Petkov , "H. Peter Anvin" , Linus Torvalds , Oleg Nesterov , Thomas Gleixner Subject: Re: [RFC PATCH 0/7] x86/entry: Create a home for the x86 entry code in arch/x86/entry/ Message-ID: <20150603171332.GD14389@gmail.com> References: <1433350757-14247-1-git-send-email-mingo@kernel.org> 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 * Andy Lutomirski wrote: > On Wed, Jun 3, 2015 at 10:07 AM, Andy Lutomirski wrote: > > On Wed, Jun 3, 2015 at 9:59 AM, Ingo Molnar wrote: > >> So the x86 syscall/irq/etc. entry code is scattered in > >> over 40 files all over the x86 architecture, making it > >> hard to get a good overview of the code and its current > >> status. > >> > >> Move all the files to arch/x86/entry/. > >> > >> This first step is as-is, no file names were changed - but the next > >> step will be to organize things in a bit more maintainable fashion. > > > > Sort of like this? > > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/entry&id=d9e37f908e8788c6d50959257f95e279ebdc821d > > > > /me cringes at the impending rebase. > > > > Anyway, I like this series except patch 7. > > > > I can't count. I mean all except patch 3 (the vdso one), not 7. > > Although arch/x86/entry might be less of a mouthful. So see my reply to hpa: it makes sense to collect all things system calls and other entry code in a single place, instead of having it scattered all around. Its internal organization is kept intact, so the vDSO code isn't mixed with other bits. Thanks, Ingo