On 16/11/18 17:29, Igor Mammedov wrote: > General suggestions for this series: > 1. Preferably don't do multiple changes within a patch > neither post huge patches (unless it's pure code movement). > (it's easy to squash patches later it necessary) > 2. Start small, pick a table generalize it and send as > one small patchset. Tables are often independent > and it's much easier on both author/reviewer to agree upon > changes and rewrite it if necessary.
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do. Paolo > 3. when you think about refactoring acpi into a generic API > think about it as routines that go into a separate library > (pure acpi spec code) and qemu/acpi glue routines and > divide them correspondingly.