qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).