* H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> I'm sorry Ingo, but this is definitely a step in the wrong direction. The only
> connection between the system call numbers and three entry code is the system
> call table, which is cleanly abstracted, so this just adds confusion, it doesn't
> improve things.
Well, the only connection between them is 'just' the system call table? :)
The deep relationship between these two entities is that one does not make much
sense without the other, in the context of a native Linux kernel!
Furthermore, to suggest that these two entities should all be in a loosely related
list of peers:
arch/x86/benchmark/
arch/x86/boot/
arch/x86/configs/
arch/x86/crypto/
arch/x86/entry/ [1]
arch/x86/ia32/
arch/x86/include/
arch/x86/kernel/
arch/x86/kvm/
arch/x86/lguest/
arch/x86/lib/
arch/x86/math-emu/
arch/x86/mm/
arch/x86/net/
arch/x86/oprofile/
arch/x86/pci/
arch/x86/platform/
arch/x86/power/
arch/x86/purgatory/
arch/x86/realmode/
arch/x86/syscalls/ [2]
arch/x86/tools/
arch/x86/um/
arch/x86/video/
arch/x86/xen/
... is a crappy argument really. There's deep, inseparable connection between [1]
and [2], and sure as hell arch/x86/entry/syscalls/ is much more strongly related
to arch/x86/entry/*.S or to arch/x86/entry/vdso/ than it is to arch/x86/pci/ or
arch/x86/boot/ !
And that's why I structured it like this:
arch/x86/entry/syscalls/ # syscall NR user-ABI definitions
arch/x86/entry/vdso/ # high level user-ABI entry implementation
arch/x86/entry/ # high level hw-ABI entry implementation
arch/x86/entry/vsyscall/ # [ legacy user-ABI entry ]
[ We also have the IRQ/NMI/trap entry code close to the system call entry code,
mostly because they are related hardware ABIs with shared hardware side
support, and because nesting irqs in system calls requires close coupling. ]
I'm not implying a parent/child relationship between the various components,
there's a graph of relationship(s) between them, and I'm also very open to
suggestions of how to better structure the entry code to express all that.
For example, as I suggested to Andy previously, I'd not mind moving the system
mode hw ABI entry code to arch/x86/entry/system/:
arch/x86/entry/syscalls/ # syscall NR user-ABI definitions
arch/x86/entry/system/ # high level hw-ABI entry implementation
arch/x86/entry/vdso/ # high level user-ABI entry implementation
arch/x86/entry/vsyscall/ # legacy user-ABI entry implementation]
But to suggest that there's only a very loose relationship between the x86 system
call numbers and the primary code that implements the high level interfaces to
them is confused at best...
Yes, there are other users: such as tracing, UML or virtualization, but those are
really just layers on top or emulation. We auto-generate the syscall mappings so
that user-space can update to our latest syscall ABI without them getting out of
sync, but what dictates in the end is the actual implementation:
- what is implemented in practice in the native system call and vDSO entry code,
as visible to user-space, i.e. what the call interface is and which generic
kernel syscall functions the various numbers map to.
Everything else primarily derives from that actual functionality of the native
entry code.
So all these closely related components are part of the same generic
arch/x86/entry/ topic, to make all these relationships easier to see and organize.
IMHO.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|