Message ID | 20190913181953.45748-1-cristian.marussi@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | Unify SMP stop generic logic to common code | expand |
On Fri, Sep 13, 2019 at 07:19:41PM +0100, Cristian Marussi wrote: > Tested as follows: > > - arm: > 1. boot So this basically means the code paths you're touching are untested on ARM... given that, and the variety of systems we have out there, why should the patches touching ARM be taken? Given that you're an ARM Ltd employee, I'm sure you can find 32-bit systems to test - or have ARM Ltd got rid of everything that isn't 64-bit? ;)
On 13/09/2019 19:27, Russell King - ARM Linux admin wrote: > On Fri, Sep 13, 2019 at 07:19:41PM +0100, Cristian Marussi wrote: >> Tested as follows: >> >> - arm: >> 1. boot > > So this basically means the code paths you're touching are untested on > ARM... given that, and the variety of systems we have out there, why > should the patches touching ARM be taken? > Yes, but sincerely it's an RFC, so I was not expecting any change to be picked up by anyone at this stage: the expectation was to have some feedback on the general approach used in the common code side of the series (patches 01-02-03-04): is it worth ? is it over-engineered ? is it badly coded ? is it complete crap ? In fact in the cover letter I stated: > A couple more of still to be done potential enhancements have been noted > on specific commits, and a lot more of testing remains surely to be done > as of now, but, in the context of this RFC, any thoughts on this approach > in general ? I didn't want to port and test a lot of architectures before having some basic feedback: in fact I did port more than one arch just to verify if they could easily all fit into the new common code logic/layout I introduced, and, also, to show that it could be generally useful to more than on arch. (as asked in V1) As you noticed, though, I did certainly test as of now a lot more on some of them: - arm64: because is where the initial bug was observed, so I had to verify if all of the above at least also fixed something at the end - x86: because the original x86 SMP stop code differs more than other archs and so it was a good challenge to see if it could fit inside the new common SMP code logic (and in fact I had to extend the common framework to fit also x86 SMP stop needs) Moreover within this series structure it is not mandatory for all archs to switch to the new common logic: if not deemed important they can simply stick to their old code, while other archs can switch to it. So testing and porting to further archs is certainly work in progress at this time, but in this RFC stage, I could be wrong, but I considered the arch-patches in this series more as an example to showcase the usefulness (or not) of the series related to the common code changes: I did not extensively tested all archs to the their full extent, so more fixes could come in V3 (if ever) together with more testing and archs. > Given that you're an ARM Ltd employee, I'm sure you can find 32-bit > systems to test - or have ARM Ltd got rid of everything that isn't > 64-bit? ;) > well...worst case there's always Amazon anyway ... :D Cheers Cristian