On 2015-08-06 08:47 PM, Krzysztof Kozlowski wrote: > 2015-08-06 22:16 GMT+09:00 nick <xerofoify@xxxxxxxxx>: >> >> >> On 2015-08-06 08:00 AM, Paolo Bonzini wrote: >>> >>> >>> On 06/08/2015 10:06, Marc Zyngier wrote: >>>>> If this structure of function pointers can handle function pointers with a return type of >>>>> void I will be glad to do what you request otherwise this would require a major rewrite >>>>> of kvm arm subsystem for a very simple bug fix. >>>> >>>> Just like Paolo said, the error you report should never happen, and >>>> would be caught by a WARN_ON() the first time anyone boots the kernel. >>>> Also, failing to register the device ops results in not being able to >>>> instantiate a VGIC. No harm done. I really don't understand why you want >>>> to rewrite the probe functions. >>> >>> I think he just misunderstood my suggestion. I didn't suggest making >>> the probe functions return void. I suggested that >>> kvm_register_device_ops return void. >>> >>> Paolo >>> >> Unfortunately the other maintainer is right in the s390 kvm subsystem uses the return value of the call to >> kvm_register_device_ops. However we could do something like a WARN_ON if kvm_register_device_ops fails in >> callers that never are required to never use it's return value. >> Sorry about the Misunderstanding as I misread your suggestion. >> Nick > > Dear Nick, > > Since you are not testing the patches, please always mark them with > RFT prefix, instead of PATCH. Someone may get confused and actually > apply untested patch. > > Best regards, > Krzysztof > Krzysztof, I am not stating your wrong here but most of my patches are either trivial bug fixes that don't need any testing or our on hardware I don't have lying around. In addition unless my bugs are hard to trace a.k.a locking issues or hardware dependent that need proof due to being unable to trace without the hardware I feel that your statement is a valid idea but may not be the best here. If you would like me to still write RFT on my patches or our concerned about me testing them I can assure you that there tested when I am able to. Cheers, Nick _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
