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.


Reply via email to