On 01/05/2012 06:07 AM, Alexander Graf wrote: > > > > Hrm. Interesting idea. So you would basically reduce everything to __u64 by padding smaller registers and splitting bigger ones into separate IDs? That really is appealing, but might uglify the code quite a bit when remerging bigger registers. For the padding things should be good. > > Ok here's another idea on how to handle this. What if we encode the register size in the constant? That way, if the register grows later, we can still be backwards compatible, but give user space exactly the size it asks for. > > We could then just take a void* from user space and merely c_t_u and c_f_u the value in exactly the size defined by the constant. > > Later, for MANY_REGS we could then just take a list of registers and write a bytestream of results to a user pointer. > > That should be a lot easier and efficient than an interface that treats everything as u64. > Yet another option is to have a large struct which we keep extending, as well as a bitmask of which fields are valid and which aren't. We'd have APIs to query the supported registers, read a struct (with all known registers filled in) and write a struct (with the bitmask indicating which registers are available). This is less flexible, but easier to use, since you don't need to decode the stream. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
