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-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
