On Wed, Jun 05, 2013 at 10:18:28PM +0100, Peter Maydell wrote: > On 5 June 2013 22:11, Andre Przywara <andre.przywara@xxxxxxxxxx> wrote: > > On 06/05/2013 09:23 PM, Christoffer Dall wrote: > >> To avoid the extra storage overhead here I suggest you just export the > >> registers using a separate number space for the ONE_REG ioctl instead of > >> piggybacking on the cp15 exports. > > This is letting the kernel's internal implementation details > affect the userspace API -- I think that's a bad idea. OK, fair enough, they can be treated as regular cp15 registers. But I looked at the patch again, and I don't see why we have to touch NR_CP15_REGS at all actually - even if we do keep the current ID for the one_reg id field. We don't need to fill in these registers in the coprocessor arrays just because they're encoded that way in the one_reg id field - that would be letting the user space API define the implementation in the kernel ;) Or did I miss something? (The truth is that the interface and implementation are probably not as separate concepts in the real world as we would sometimes like, but that's a different discussion.) > As Andre says, we went through a round like this, and my > opinion was that since these are cp15 registers the logical > place to put them is in cp15 space. > Well, that round wasn't public, so I didn't really have that background info, but I agree with your sentiment, and it does avoid us having to come up with encoding in an already existing number space (the cp15 access numbers), but we want it to make sense for both the kernel and user space applications, and we don't want to be allocating random unused bytes on kernel data structures just for the fun of it. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
