Heiko Carstens wrote: >>> >>> >> What benefit would a syscall interface have? >> > > Another thing is that this patch set already introduces a way to pass a > sigset. Passing a sigset to a device node is sort of strange. >
The sigset is passed to the device node just for safekeeping, as it doesn't normally change. It's only used when switching to guest mode. > In addition, if we would port kvm to s390, then we would need to > make sure that each virtual cpu only gets executed from the thread > that created it. That is simply because the upper half of our page > tables contain information about the guest page states. This is yet > another thing that would be strange to do via an ioctl based interface. > Right. I agree it's more natural to associate a vcpu with a task instead of a vcpu being an independent entry. We'd still need a handle for it, and in Linux that's an fd (pid doesn't cut it as it's racy, and probably slower too as it has to go through a global structure). > Of course everthing can be done via an iotcl interface too, but IMHO > that's just the wrong interface. > I guess once we have smp, and preferably an additional arch port, we can do another round of API consolidation around a syscall based API. We'll need to support the ioctl based API in parallel until the distros flush out older userspace. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
