Am 22.08.2012 um 16:54 schrieb Rusty Russell <rusty.russell@xxxxxxxxxx>: > On Tue, 21 Aug 2012 09:35:21 +0200, Alexander Graf <agraf@xxxxxxx> wrote: >> On 21.08.2012, at 04:32, Rusty Russell <rusty.russell@xxxxxxxxxx> wrote: >>> Now, if Anthony and Avi lay down the law and say everyone is moving to a >>> new system, we'll move now. For real: I want to see x86 patches. >> >> So because x86 has a stable API today that works for them and that >> needs to be supported anyways we don't improve the non-x86 code? What >> an awesome argument. I should bring that one up next time I don't want >> to think about something. > > It's not an improvement. You want change, so we can unify. But it > won't actually unify anything important, since x86 will not be unified. > Right? > >>> Otherwise, we'll concentrate on stuff we know, and transition when >>> everyone else does. >>> >>> And since that transition is likely to be painful and of no real >>> benefit, it might never happen. >> >> That's exactly my point. Today you have the chance and could go with >> something generic, extensible. > > Today? No, you don't have what we need today. > >> In fact, you basically reimplemented ONE_REG on top of the x86 MSR >> ioctls. > > Not if you order your narrative in linear time. You reimplemented MSR, > badly. I copied MSR, and ignored ONE_REG altogether. > >> So either try to work with everyone on a solution for everyone, rename the ioctls to something more generic, or invent new ones for you. But don't create another arm-one-reg api under the MSR code name. > > We could easily rename ARM's MSR-style ioctls to sound generic. We > could reserve the upper 6 bits of the index for an architecture tag so > everyone has their own namespace, or just bloat the index to 64 bits. > > But will it be any more successful than ONE_REG? What would we gain? > > Are you going to be at KS/Plumbers? Avi, you? Because grand plans seem > to work badly over email. Yes, we're both at Plumbers, Avi is also at KS and we're both in SD right now. I agree. Let's take this to a discussin at Plumbers. I think you just look at this from a different perspective. To me, the ONE_REG ioctls were just the best way to implement what is necessary to poke at a single register, because that's what I needed at the time. The great improvement / master plan that is behind ONE_REG is that every register gets a unique id that any other ioctl could use. Not the way we use that ID today. I don't care what we call the ioctl. Ihe implementation of how we access registers could change. But at least we have a stable number space that won't break as easily as struct offsets and doesn't require us to move structs left and right, wasting memory, time and brainpower. Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
