qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: J. Mayer
Subject: Re: [Qemu-devel] How to split vl.h
Date: Sun, 04 Nov 2007 20:41:27 +0100

On Sun, 2007-11-04 at 17:54 +0000, Paul Brook wrote:
> On Sunday 04 November 2007, J. Mayer wrote:
> > On Sun, 2007-11-04 at 12:17 +0000, Paul Brook wrote:
> > > > I have another solution: include all architecture specific files from
> > > > the main file.
> > >
> > > I'd really rather not do this. I doubt it's going to be a win, as now you
> > > have to recompile the whole thing every time you change the
> > > implementation. At least with vl.h you only have to recompile when you
> > > change the interface.
> >
> > What I feel about this is that adding a hw/hw.h, included in all hw/*.c
> > files would greatly improve the situation: changing vl.h would lead to
> > recompile the core emulator object files, changing hw/hw.h would lead to
> > recompile the hardware library.
> 
> Well, most of the "core emulator" doesn't depend on vl.h anyway. It's just 
> the 
> device emulation and host disk/display code.
> 
> I not sure a single hw/hw.h file will give any benefit because there's a fair 
> amount of interfacing between the target devices emulation and the host side 
> interaction code. i.e. there's not much that's only used inside hw/.
> hw/ is about as big as most of the rest of qemu put together, so splitting 
> that is probably going to get the biggest wins.

hw library contains a lot of code but is not all is compiled for all
targets.

> How about dividing things up by category? e.g. Have header files for all of 
> (in no particular order):
> 
> - Things includes by everything
> - The block IO layer.
> - The character IO layer
> - Network IO layer.
> - Display interface.
> - Generic Device infrastructure (memory mapping, IRQs, etc). Maybe subdivide 
> for common busses like scsi/usb/pci/i2c.
> - Prototypes for device emulation init routines.
> 
> Each file can then include whichever categories it needs.

Yes, it could be a great solution. Mine was just the "quick and less
effort" proposal !
It seems you also should have headers for target specific declarations.
This would avoid recompiling all targets when working on devices
specific to only one or a few of them.

-- 
J. Mayer <address@hidden>
Never organized





reply via email to

[Prev in Thread] Current Thread [Next in Thread]