Re: [Qemu-devel] How to split vl.h

[Jocelyn Mayer]

On Wed, 2007-10-31 at 20:12 +0200, Blue Swirl wrote:
> Hi,

Hi,

> With the automatic dependency rule installed, modifying vl.h causes
> all files to be recompiled. This is of course the correct action, but
> it's a major slowdown for development too.
> 
> How should we split vl.h into smaller pieces? Give each device a
> header file, like m48t59? What about other stuff exported from vl.c?

It seems to me that a lot of things could go back in headers in the hw
subdirectory. A quick and simple approach could be to create a hw/hw.h
file and move everything from vl.h that is only used in the hw
subdirectory. This way, we would break the strong compile-time
dependencies between the hardware library and the rest of the emulation
code.

I think there are some things, like PC serial, USB, ... that could be
left in this kind of header without any issue: they're widely used and
are not likely to change too often.
Some other architecture specific devices would better have their own
header (like the m48t59.h file) or maybe a target dependant header could
be sufficient (quite like the ppc_mac.h I added a few days ago). Having
this kind of header could also be great so we could put the machines
extern definition in it and only include this header file in vl.c (not
vl.h !) to get, for example, the defined machine list for the current
target architecture (and not all possible machines as it is now)...

It also seems that some hardware dependent stuffs are currently
implemented in vl.c, like the bloc devices or USB registration code,
that prevent the related definitions to be isolated in the hw
subdirectory. Splitting vl.c to move those functions into separate
file(s) in hw would allow moving a lot of definitions in the hw
subdirectory. Ideally, vl.c should be hw / target independant and call
the proper routines to do all hardware implementation dependant
initialisations, imho.

Those are just ideas, maybe some are too complicated to be done in a
short timeline; and there may be better solutions... if any other
ideas...

-- 
Jocelyn Mayer <address@hidden>