From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>, Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] How to split vl.h
Date: Sun, 04 Nov 2007 20:41:27 +0100 [thread overview]
Message-ID: <1194205288.31210.47.camel@rapid> (raw)
In-Reply-To: <200711041754.55320.paul@codesourcery.com>
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 <l_indien@magic.fr>
Never organized
next prev parent reply other threads:[~2007-11-04 19:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 18:12 [Qemu-devel] How to split vl.h Blue Swirl
2007-10-31 19:35 ` Jocelyn Mayer
2007-10-31 23:06 ` Thiemo Seufer
2007-11-01 11:16 ` Fabrice Bellard
2007-11-01 13:32 ` Stefan Weil
2007-11-01 14:11 ` andrzej zaborowski
2007-11-04 8:48 ` Blue Swirl
2007-11-04 12:17 ` Paul Brook
2007-11-04 17:23 ` J. Mayer
2007-11-04 17:54 ` Paul Brook
2007-11-04 19:41 ` J. Mayer [this message]
2007-11-04 21:30 ` Paul Brook
2007-11-04 23:38 ` Thiemo Seufer
2007-11-04 18:06 ` Thiemo Seufer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1194205288.31210.47.camel@rapid \
--to=l_indien@magic.fr \
--cc=blauwirbel@gmail.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).