From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965387AbbFCRRV (ORCPT ); Wed, 3 Jun 2015 13:17:21 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:33818 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965359AbbFCRQz (ORCPT ); Wed, 3 Jun 2015 13:16:55 -0400 Date: Wed, 3 Jun 2015 19:16:50 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , Denys Vlasenko , Brian Gerst , Peter Zijlstra , Borislav Petkov , 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: <20150603171650.GA15858@gmail.com> References: <1433350757-14247-1-git-send-email-mingo@kernel.org> <556F3368.5060708@zytor.com> <20150603171100.GB14389@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 * Andy Lutomirski wrote: > On Wed, Jun 3, 2015 at 10:11 AM, Ingo Molnar wrote: > > > > * H. Peter Anvin wrote: > > > >> I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason > >> for that is that it really isn't entry code, it is user space code. > > > > Well, I think arch/x86/entry/ should be a broader category for all things entry > > code: and the vsyscall code is closely related to the syscall entry/exit code so > > it's in a better place there than just being in the generic arch/x86/kernel/ > > directory. > > > > I kept it separate in arch/x86/entry/vsyscall/ so it doesn't mix with other entry > > code. > > ...and my reading comprehension is way off this morning. You already called it > arch/x86/entry, so there was no reason for me to suggest that :) > > Anyway, arch/x86/entry/vdso isn't so bad. It's just a bit odd sounding to me. We could make it arch/x86/sys/? Sounds a bit too generic though. Didn't want to limit it to system calls only, because there's various other entry methods (irqs, traps, NMI, etc.) that we want to handle in a coherent fashion. [ Which you are intimately aware of ;-) ] Thanks, Ingo