Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1611755
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree |
| Date | 2017-03-29 11:50 +0200 |
| Message-ID | <tqioP-51x-29@gated-at.bofh.it> (permalink) |
| References | <tqc9H-L5-9@gated-at.bofh.it> <tqi5s-4RU-11@gated-at.bofh.it> <tqif7-4VF-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 29/03/2017 11:29, Christian Borntraeger wrote: >>> -#define KVM_CAP_S390_GS 137 >>> +#define KVM_CAP_MIPS_VZ 137 >>> +#define KVM_CAP_MIPS_TE 138 >>> +#define KVM_CAP_MIPS_64BIT 139 >>> ++#define KVM_CAP_S390_GS 140 >>> >>> #ifdef KVM_CAP_IRQ_ROUTING >> Thanks Stephen, >> >> Cc'ing Paulo and Radim. >> >> This does seem a bit of a conflict magnet, and they're part of the user >> ABI so when the values change upon merge, the intermediate versions >> before and after require different userland builds. >> >> Should the numbering be decided in advance somehow (i.e. in response to >> conflicts in linux-next)? I don't particularly want to change the >> numbering again as others would need rebuilds again, but I only just >> pushed the MIPS changes, so if I change the MIPS numbering to 138-140, >> can we expect other branches to continue at 141 so I don't need to >> change them again? Yes, that can be expected. If you don't do it, I'll bump the capability number as soon as I get the conflict. If it's an issue, the solution is topic branches: as soon as you need a capability, fire a pull request so that it gets in kvm/next. But it doesn't happen too often, the last times were in 4.1, 4.6 and 4.8 (three times in 2 years). >> Alternatively does it make sense to have different ranges reserved for >> different architectures (like the get one reg numbers)? > > I can live with a changing GS capability number, so keep your number. > In the end I think Radim/Paolo will do the assigment when merging. Yes---and in that case it's first come first served. Same for ioctls, though those change even more rarely. Paolo > And no userspace should rely on this before this is at least in kvm/next > Yes, this will be a bit of pain for internal QA, but this worked ok > for the last 3 or 4 years on our side
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
linux-next: manual merge of the kvms390 tree with the kvm-mips tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-03-29 05:10 +0200
Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree James Hogan <james.hogan@imgtec.com> - 2017-03-29 11:30 +0200
Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree Christian Borntraeger <borntraeger@de.ibm.com> - 2017-03-29 11:40 +0200
Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree Paolo Bonzini <pbonzini@redhat.com> - 2017-03-29 11:50 +0200
Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree James Hogan <james.hogan@imgtec.com> - 2017-03-29 13:30 +0200
csiph-web