On 04/19/2018 10:29 AM, Borislav Petkov wrote: > On Thu, Apr 19, 2018 at 09:57:08AM -0500, Alex G. wrote: >> And that was the motivation behind my splitting it in this patch. > > By "split" I don't mean add a function pointer which gets selected and > then called - if the function becomes too long, you simply split the > function body properly. The bulk of the function is the if/else mapping from UUID to error handler. I don't see how that can be easily split up, hence why I originally resorted to the mapping. As you said, we'll keep it simple at first. >> You don't need the entire GHES structure -- wide context. Individual >> handlers should not be able to access the entire ghes. > > But you remove the @ghes argument in patch 1. So what are we even > talking about? You could say, by convention, handlers shouldn't access ghes directly, but that is not obvious when @ghes is in scope. The reason I bring it up is that, if [1/4] ends up being unneeded, then I will drop it from the series. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
