On 13/05/2020 22.43, John Snow wrote: > > > On 5/7/20 10:05 AM, Philippe Mathieu-Daudé wrote: >> +Hervé >> >> On 5/7/20 3:16 PM, Gerd Hoffmann wrote: >>> Signed-off-by: Gerd Hoffmann <kra...@redhat.com> >>> Reviewed-by: Igor Mammedov <imamm...@redhat.com> >>> --- >>> hw/block/fdc.c | 83 ++++++++++++++++++++++++++++++++++++++++++++ > > oh no... > >>> hw/i386/acpi-build.c | 83 -------------------------------------------- >>> stubs/cmos.c | 7 ++++ >>> stubs/Makefile.objs | 1 + >>> 4 files changed, 91 insertions(+), 83 deletions(-) >>> create mode 100644 stubs/cmos.c >>> >>> diff --git a/hw/block/fdc.c b/hw/block/fdc.c >>> index 9628cc171ef8..40faa088b5f7 100644 >>> --- a/hw/block/fdc.c >>> +++ b/hw/block/fdc.c >>> @@ -32,6 +32,8 @@ >>> #include "qapi/error.h" >>> #include "qemu/error-report.h" >>> #include "qemu/timer.h" >>> +#include "hw/i386/pc.h" >> >> I'd rather not see this target-specific header used in the generic >> device model... The culprit seems cmos_get_fd_drive_type(). Is the value >> really PC specific? >> >> Hervé, do you know if such info & RTC nvram layout is used in other arch? >> > > do we need pc-only floppy code somewhere to keep the makefile pure?
Yes, please put this into a separate file that only gets build if the corresponding CONFIG switches are set. That way you should also get along without that new stubs/cmos.c file. Thomas
