On Wed, Nov 18, 2015 at 10:29:30AM +0000, Andre Przywara wrote: > On 02/11/15 14:58, Will Deacon wrote: > > On Fri, Oct 30, 2015 at 06:26:53PM +0000, Andre Przywara wrote: > >> this series cleans up kvmtool's kernel loading functionality a bit. > >> It has been broken out of a previous series I sent [1] and contains > >> just the cleanup and bug fix parts, which should be less controversial > >> and thus easier to merge ;-) > >> I will resend the pipe loading part later on as a separate series. > >> > >> The first patch properly abstracts kernel loading to move > >> responsibility into each architecture's code. It removes quite some > >> ugly code from the generic kvm.c file. > >> The later patches address the naive usage of read(2) to, well, read > >> data from files. Doing this without coping with the subtleties of > >> the UNIX read semantics (returning with less or none data read is not > >> an error) can provoke hard to debug failures. > >> So these patches make use of the existing and one new wrapper function > >> to make sure we read everything we actually wanted to. > >> The last patch moves the ARM kernel loading code into the proper > >> location to be in line with the other architectures. > >> > >> Please have a look and give some comments! > > > > Looks good to me, but I'd like to see some comments from some mips/ppc/x86 > > people on the changes you're making over there. > > Sounds reasonable, but no answers yet. > > Can you take at least patch 1 and 2 meanwhile, preferably 6 and 7 (the > ARM parts) also if you are OK with it? > I have other patches that depend on 1/7 and 2/7, so having them upstream > would help me and reduce further dependency churn. > I am happy to resend the remaining patches for further discussion later.
We let them sit on the list for a while with no comments, so I just pushed out your series. If a bug report shows up, then we can always revert the offending patch if there's no quick fix. Will -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
