David Miller writes: > From: Paul Mackerras <[EMAIL PROTECTED]> > Date: Thu, 15 Nov 2007 10:12:22 +1100 > > > *I* never had a problem with a few extra system calls. I don't > > understand why you (apparently) do. > > We're stuck with them forever, they are hard to version and extend > cleanly. > > Those are my main objections.
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. - 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/
