The first is valid (for suitable values of "forever") but applies to
any user/kernel interface, not just system calls.
As for the second (hard to version) I don't see why it applies to
syscalls specifically more than to other interfaces. It's just a
matter of designing it correctly in the first place. For example, the
sys_swapcontext system call we have on powerpc takes an argument which
is the size of the ucontext_t that userland is using, which allows us
to extend it in future if necessary. (Note that I'm not saying that
the current perfmon2 interfaces are well-designed in this respect.)
The third (hard to extend cleanly) is a good point, and is a valid
criticism of the current set of perfmon2 system calls, I think.
However, the goal of being able to extend the interface tends to be in
opposition to the goal of having strong typing of the interface.
Things like a multiplexed syscall or an ioctl are much easier to
extend but that is at the expense of losing strong typing. Something
like my transaction() (or your weird kind of read() :) also provides
extensibility but loses type safety to some degree.
Also, as Andi says, this is core CPU state that we are dealing with,
not some I/O device, so treating the whole of perfmon2 (or any
performance monitoring infrastructure) as a driver doesn't fit very
well, and in fact system calls are appropriate. Just like we don't
try to make access to debugging facilities fit into a driver, we
shouldn't make performance monitoring fit into a driver either.
Paul.
-
