On Wed, Jun 3, 2015 at 10:21 AM, Ingo Molnar <[email protected]> wrote: > > * Ingo Molnar <[email protected]> wrote: > >> >> * Andy Lutomirski <[email protected]> wrote: >> >> > On Wed, Jun 3, 2015 at 10:11 AM, Ingo Molnar <[email protected]> wrote: >> > > >> > > * H. Peter Anvin <[email protected]> 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. Once this is in, I'll rebase my code movement change and send it, although I probably won't call the result arch/x86/entry/entry.c :) And then it'll be back to grumbling at context tracking. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
