On 11.03.2026 19:01, Alejandro Vallejo wrote: > On Wed Mar 11, 2026 at 3:59 PM CET, Jan Beulich wrote: >> On 11.03.2026 15:27, Alejandro Vallejo wrote: >>> Remove cross-vendor support now that VMs can no longer have a different >>> vendor than the host. >>> >>> While at it, refactor the function to exit early and skip initialising >>> the emulation context when FEP is not enabled. >>> >>> No functional change intended. >>> >>> Signed-off-by: Alejandro Vallejo <[email protected]> >>> --- >>> v4: >>> * Reverted refactor of the `walk` variable assignment >> >> "Revert" as in "move it even farther away from the original". > > Revert as in not split the assignment and restore the orignal syntax _of the > assignment_, which was the main focus of the prior discussion. > > It's hardly my intention to add unrequested changes, but I can't address that > which isn't explicitly requested. > >> As said, you want re-indentation, > > This is an ambiguous piece of advice. > > Of what? That can mean moving the prior logic back to its original location > and > crate a minimal diff (1) or simply collapsing the indentation of the block > (2). > > (1) can't be done with hvm context initialiser moving after the early exit, > which I explicitly mentioned in the commit message I wanted to do. > > (2) can't happen because declarations and statements cannot be mixed (though I > really wish we dropped that rule). > > There's a third option of keeping a silly { ... } around just for indentation > purposes, but that's worse than either of the other 2 options. > > Maybe there's a fourth code arrangement in your head that does all this in a > way you find less intrusive and I just don't see it. If so, feel free to send > a patch I can review. It'll be faster for the both of us. Or tell me precisely > what's at fault here. > > If it's the diff, I'll go for option (1) above. I don't care enough about it > to > argue. > >> so please do just that, nothing else that isn't >> explicitly justified (like the moving of hvm_emulate_init_once() is). > > I'm not sure if you're fine with that motion because it's in the commit > message > or not because it's a refactor that shouldn't be in the patch. This statement > can be read either way.
You justify that movement in the description, and I agree with that justification. >> With >> this put back in its original shape (can do while committing, I suppose): >> Reviewed-by: Jan Beulich <[email protected]> > > I don't think it's very obvious what you mean to do on commit, so it wouldn't > be > appropriate to agree to your adjustments, seeing how I just don't know what > they > are. I'm happy to send a v4.5 on this particular patch with whatever else > needs > modifying. Or a full v5 even. Or review whatever you wish to send as a v4.5 of > this patch. The variable had an initializer, and mere re-indentation wants to keep it so. (There's no question that declarations may need to move, for the result to still compile.) Jan
