From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754565AbbFCR3Y (ORCPT ); Wed, 3 Jun 2015 13:29:24 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:34500 "EHLO mail-wg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753269AbbFCR3P (ORCPT ); Wed, 3 Jun 2015 13:29:15 -0400 Date: Wed, 3 Jun 2015 19:29:10 +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: <20150603172910.GA16982@gmail.com> References: <1433350757-14247-1-git-send-email-mingo@kernel.org> <556F3368.5060708@zytor.com> <20150603171100.GB14389@gmail.com> <20150603171650.GA15858@gmail.com> <20150603172146.GA16278@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:21 AM, Ingo Molnar wrote: > > > > * Ingo Molnar wrote: > > > >> > >> * 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 ;-) ] > > > > Another tweak would be to move the kernel side entry code into > > arch/x86/entry/system/ or so, to create the following organization: > > > > arch/x86/entry: all things entry methods > > > > arch/x86/entry/system/: system/kernel mode entry code > > arch/x86/entry/vdso/: user mode entry code > > arch/x86/entry/vsyscall/: [legacy vsyscall entry code] > > > > arch/x86/entry/syscalls/: build-time syscall table generation code > > > > My primary goal is to have them all close to each other, so that we can have > > better structure, more coherency and easier overview. The names are negotiable, > > the concept is not ;-) > > I think I like the approach in the patches you sent better. Ok. > Once this is in, I'll rebase my code movement change and send it, Sounds good to me! > although I probably won't call the result arch/x86/entry/entry.c :) A few naming suggestions: arch/x86/entry/core.c arch/x86/entry/sys.c arch/x86/entry/kernel.c ;-) Note ... I'd love to split up the various entry methods into separate files - but will do that only on top of your C based bits. And once that is done, the names of those files will be obvious and clean: arch/x86/entry/syscall.c arch/x86/entry/irq.c arch/x86/entry/traps.c arch/x86/entry/nmi.c arch/x86/entry/et.c > And then it'll be back to grumbling at context tracking. Uh oh ... Thanks, Ingo