On 03/05/2012 05:15 PM, Anthony Liguori wrote: >> The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory >> API. I think 32-on-32 is quite rare these days, so it wouldn't be much >> of a performance issue. > > > I think this makes sense independent of other discussions regarding > fixing target_phys_addr_t size. > > Hardware addresses should be independent of the target. If we wanted > to use a hw_addr_t that would be okay too. > Would this hw_addr (s/_t$//, or you'll be Blued) be fixed at uint64_t (and thus only documentary), or also subject to multiple compilation? -- 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
