This is a continuation of a conversation I have been having with Izik Eidus on IRC today.
I plan on moving x86 code out of kvm.h and into kvm-x86.h. kvm-x86.h would then include kvm.h and would be included by files like svm.c instead of kvm.h. Izik pointed out a big issue with this approach and that is it breaks compatibility with older userspace. We believe that everyone still cares that older userspace should be able to compile against a newer kvm kernels. Is this true or should we just dump it? Assuming this is true, we have come up with an interesting solution to the problem. - creation of new header name "portablekvm.h" (please give a better name if you know one). This would be the new place for common code that would normally be kvm.h. - still create header "kvm-x86.h" for x86 code and would include this new "portablekvm.h" header. - keep compatibility with older userspace by taking header "kvm.h" and jsut have it include kvm-x86.h & portablekvm.h and have no other code (unless it's for compatibility). What does everyone thing about this ? Also a side discussion is should we really start thinking about having a userspace header and stop userspace apps from including kernel headers. This does lead to a problem where if the kernel header is updated the userspace header must also be updated (but maybe it's time to bite the bullet)? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
