> --- a/target-s390x/cpu.h
> +++ b/target-s390x/cpu.h
> @@ -30,8 +30,7 @@
>
> #include "softfloat.h"
>
> -#define NB_MMU_MODES 2 // guess
> -#define MMU_USER_IDX 0 // guess
> +#define NB_MMU_MODES 2
The fact that you're modifying a file you added earlier in the same patch
series gives me very
> > Reading in old state files is a whole lot easier (to write
> > maintain, and stay sane) than producing state that is bug-compatible with
> > previous versions.
>
> It seems to me that old->new and new->old migrations are
> of about the same level of difficulty.
> Supporting one of these but no
On Tuesday 24 November 2009, Gerd Hoffmann wrote:
> On 11/16/09 19:53, Paul Brook wrote:
> > Capping the amount of memory required for a transfer *is* implemented, in
> > both LSI and virtio-blk. The exception being SCSI passthrough where the
> > kernel API makes it
> But it's easy to support migration to old qemu just
> by discarding the INTx state, and this is not
> at all harder, or worse, than migrating from old qemu
> to new one.
Do we really care about migrating to older versions?
Migrating to a new version (backward compatibility) I see the use, it al
On Sunday 22 November 2009, Stefan Weil wrote:
> All files config-devices.mak are copies from files in
> directory default-configs.
See commit a992fe3, specifically "make defconfig".
Paul
On Monday 23 November 2009, Gerd Hoffmann wrote:
> On 11/23/09 14:26, Paul Brook wrote:
> > I thinking more that this should be done by the character backend itself.
> > For example, the "graphical" consoles should probably be putting this as
> > part of the wind
On Monday 23 November 2009, Gerd Hoffmann wrote:
> On 11/20/09 18:41, Paul Brook wrote:
> > On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> >> Add a greeting string to CharDriverState which is printed after
> >> initialization. Used to have the qemu vc consoles lab
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> Add a greeting string to CharDriverState which is printed after
> initialization. Used to have the qemu vc consoles labeled. This
> way we can avoid walking all the chardevs a second time after
> initialization just to print the greeting.
I thi
> > That's an option, basically keeping the list (or only one ?) of aliased
> > TCG variables for each of them, and freeing the others before using one.
>
> Yeah, only one. I don't think this should be getting overengineered (and
> thus slow) :-).
> Doesn't really sound hard, does it? Any TCG magi
> > Why aren't you also using this function in scsi- disc.c? Surely that's the
> > whole point of moving it into common code.
>
> Same as with the command move: next patch series will rework scsi-disk
> to put the new fields and functions into use.
Hmm, maybe you need to rethink your patch sequen
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> On 11/17/09 13:36, Paul Brook wrote:
> >>> In fact I'd much prefer to see extboot rewritten to just virtio-block.
> >>
> >> Hmm, I'd prefer something which is *not* used by the guest OS, so it is
>
On Tuesday 17 November 2009, Ian Molton wrote:
> Hi,
>
> Qemu currently is making a bit of a hash of parsing suffixes,
>
> Right now, it has:
>
> T, G, M, and K which are multiples of 1024 bytes - fair enough
>
> but it also has:
>
> k - 1024 (should be 1000)
>
> and b:
>
> Byte (also wron
> > In fact I'd much prefer to see extboot rewritten to just virtio-block.
>
> Hmm, I'd prefer something which is *not* used by the guest OS, so it is
> a pure bootloader thing. When using it to boot from scsi you don't want
> to have the disk show up twice (as virtio and scsi) in the guest.
You
On Tuesday 17 November 2009, Christoph Hellwig wrote:
> The subject is a bit confusing - it's not the full request parsing but
> just some helpers.
This is a good example of a patch with an insufficient commit message.
Given the way GIT treats the first line of the commit mesaage, my advice is to
> > The practical example below will explain it completely:
> >
> > 1) we take 4 common modern computers - CoreQuad + 8 GB Memory.
> > 2) we assemble a standard Linux cluster with 16 cores and 32G memory.
> > 3) and now - we run the only one virtual guest system, but give it ALL
> > available resou
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> Changes:
> * Move from open-coded lists to QTAILQ macros.
> * Move the struct elements to the common data structures
>(SCSIDevice + SCSIRequest).
> * Fix request cleanup in the destroy callback.
This feels like the abstraction boundaries w
> add xfer mode
This should also be used by scsi-disc.c
Paul
> move scsi command from SCSIGenericReq to SCSIRequest.
Why? AFAICS This has precisely one user, and more importantly it is not
populated by scsi-disk.c.
Sharing common code is good. Implementing shared fields inconsistently or
putting implementation specific fields in common structures.
Paul
> >> It would require a mechanism to do enumeration and identification
> >> though.
> >
> > Huh? Do you want export *all* block devices via extboot? Will IDE
> > drives show up twice then?
>
> No, because SeaBIOS already has an ATA driver so we wouldn't want to
> expose IDE on the extboot bus.
On Monday 16 November 2009, Gerd Hoffmann wrote:
> On 11/11/09 17:38, Paul Brook wrote:
> >>> That cap is important.
> >>> For scsi-generic you probably don't have a choice because of the way
> >>> the kernel interface works.
> >>
> >>
> > While sync appears attractive as a quick hack to achieve this, I think it
> > is liable to be abused, and cause us serious pain long-term. If you need
> > an easy solution then use ld/st (as with ARM VFP registers). If you want
> > a good solution then fix whichever bit of TCG makes accessing a
> I'm writing a virtio-rng host-side driver for qemu-kvm, and I've got
> something up and running that works, and will pass data gathered from a
> char device on the host through to the virtio-rng driver on a guest copy
> of linux.
Why do you need a special device? Isn't a regular serial data stre
> > This is latent breakage introduced by 45a50b1.
> > See commits 97fe84f5 (makes breakage obvious) and f2d7497 (fixed ARM).
> > MIPS still needs fixing.
>
> I can't find 97fe84f5 or f2d7497, what commits are those?
http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=97fe84f5
http://git.savanna
On Tuesday 10 November 2009, Aurelien Jarno wrote:
> On Tue, Nov 10, 2009 at 11:19:40PM +0200, Blue Swirl wrote:
> > On Tue, Nov 10, 2009 at 10:50 PM, Aurelien Jarno
wrote:
> > > Please note that at least qemu-system-arm, qemu-system-mips and
> > > qemu-system-mipsel are broken by this commit:
>
>> That cap is important.
>> For scsi-generic you probably don't have a choice because of the way the
>> kernel interface works.
>
>Exactly. And why is the cap important for scsi-disk if scsi-generic
>does fine without?
With scsi-generic you're at the mercy of what the kernel API gives you, and i
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> On Wed, Nov 11, 2009 at 02:16:00PM +0000, Paul Brook wrote:
> > On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> > > On Wed, Nov 11, 2009 at 01:45:35PM +, Paul Brook wrote:
> > > > If you don&
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> On Wed, Nov 11, 2009 at 01:45:35PM +0000, Paul Brook wrote:
> > If you don't need real barriers, then why does the kvm code have them?
>
> We need real barriers but AFAIK kvm does not have them :(
> IOW: virtio i
> The current qemu code *does* cache the response. scsi-disk caps the
> buffer at 128k (which is big enough for any request I've seen in my
> testing). scsi-generic has no cap.
That cap is important.
For scsi-generic you probably don't have a choice because of the way the
kernel interface works
On Wednesday 11 November 2009, Anthony Liguori wrote:
> Hannes Reinecke wrote:
> > But why? Why do we have to emulate the entire HBA for the BIOS?
> > The HBA is emulated, too, and just uses the bdrv interface
> > internally anyway.
> > So IMHO it makes far more sense to skip the HBA emulation in
>
> > > > > wmb must be at least a compiler barrier, even without SMP.
> > > >
> > > > Why?
> > >
> > > Because virtio code might run on a separate thread from guest.
> > > If compiler reorders writes, guest might see inconsistent data.
> >
> > If you've got threads running in parallel (which may be
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> On Wed, Nov 11, 2009 at 01:34:12AM +0000, Paul Brook wrote:
> > On Monday 26 October 2009, Michael S. Tsirkin wrote:
> > > wmb must be at least a compiler barrier, even without SMP.
> >
> > Why?
>
>
On Wednesday 11 November 2009, Scott Tsai wrote:
> I reworked the second patch in this series to add generic monitor commands
> to change the temperature reported from thermometers.
> Thermometer devices can now include "sensor.h" and call
> 'qemu_add_therm_temp_handler' to register themselves.
T
On Friday 06 November 2009, Gerd Hoffmann wrote:
>Hi,
>
> http://repo.or.cz/w/qemu/kraxel.git/shortlog/refs/heads/scsi.v6
>
> What is in there?
> (3) New interface for HBA <=> SCSIDevice interaction:
> * building on the new SCSIRequest struct.
> * the silly read_data/write_data
On Thursday 05 November 2009, Juan Quintela wrote:
> Daniel Jacobowitz wrote:
> > On Thu, Nov 05, 2009 at 05:17:46PM +0100, Juan Quintela wrote:
> >> How are you compiling?
> >> It works for me compiling in-tree with make -j3 (only 2 cores)
> >
> > I can reliably reproduce it by building all my QE
> But I certainly do _not_ want to update the SCSI disk
> emulation, as this is really quite tied to the SCSI parallel
> interface used by the old lsi53c895a.c.
This is completely untrue. scsi-disk.c contains no transport-specific code. It
is deliberately designed to be independent of both the tr
On Monday 26 October 2009, Michael S. Tsirkin wrote:
> wmb must be at least a compiler barrier, even without SMP.
Why?
Paul
> I immediately reproduced the problem locally. It turns out that
> kvm reflects packets coming from one guest NIC on another guest
> NIC, and since both are connected to the same bridge we're getting
> endless packet storm. To a level when kvm process becomes 100%
> busy and does not respond to
On Thursday 22 October 2009, Aurelien Jarno wrote:
> On Wed, Oct 21, 2009 at 03:52:22PM +0200, Ulrich Hecht wrote:
> > sync allows concurrent accesses to locations in memory through different
> > TCG variables. This comes in handy when you are emulating CPU registers
> > that can be used as either
> On the code itself, I don't really like the remaining, new_tmp(),
> dead_tmp(), and even more the fact that some functions can allocate
> (e.g load_reg) or free (e.g. store_reg) some TCG variables implicitely.
> This is a way to make errors by reallocating or forgetting to free some
>
> variable
> > Some of the generated tcg code is not very optimal, for example a
> > single vld4.8 instruction can generate over 250 tcg ops. I did some
> > optimizations and got it under 200 but do you think it could be an
> > issue that a single instruction can expand to so many tcg ops? I mean
> > besides
On Monday 12 October 2009, Toni wrote:
> Hi guys,
> I found a solution for the problems with the fork and the exec under qemu
> user-mode.
> With the fork I enabled the NPTL and now it seems to work fine.
> For the exec the problem was that it was execute natively, and so the qemu
> process was kil
On Thursday 08 October 2009, Mark McLoughlin wrote:
> Hi,
> Here's a series of patches which gets the ball rolling on adding
> a -netdev option.
>...
> The idea is to de-emphasise the vlan support, and instead make
> a nic directly connected to a host backend the default and recomme
On Wednesday 30 September 2009, Aurelien Jarno wrote:
> Currently zero extensions ops are implemented by a and op with a
> constant. This is then catched in some backend, and replaced by
> a zero extension instruction. While this works well on RISC
> machines, this adds a useless register move on n
> No question, this is a gdb issue. But, as it was confirmed in several
> discusssions with gdb people, it is a non-trivial thing to fix. So until
> qemu finds a gdb version attach with a rework x86 support, we have to
> work around it by switching the register layout as the guest switches
> its ex
On Friday 11 September 2009, Anthony Liguori wrote:
> malc wrote:
> > And generalizations are always true. Anyhow, i'm explicitly against the
> > patch, so first obtain the express acknowledgment from the leaders,
> > otherwise i'll revert it should it go in.
>
> I'm adding the following patch to
On Tuesday 08 September 2009, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
> > $subject says pretty much everything.
> >
> > extboot.[cS] are a straight copy from the kvm tree. The windup in vl,c
> > and hw/pc.c is done slightly different, I've added a function to lookup
> > the boot drive instea
On Saturday 15 March 2008, Peter Volkov wrote:
> Hello.
>
> I just wanted to point developers attention to the following bug:
> bugs.gentoo.org/212351 , comment #11 and further. The problem is that
> qemu does not compile any more on x86. I've tried recent snapshot
> (2008-03-15_05) and the problem
> gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)
Which part of "gcc 4.x is not supported" didn't you understand?
Paul
> That's the '&' which is wrong here. The string can be accessed with
> *((uint32_t *)devid). So you can simply use:
>
> ret = le32_to_cpu(*((uint32_t *)devid))
No you can't. Even ignoring the aliasing violation, devid might not be
sufficiently aligned.
Paul
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/03/04 23:52:48
Modified files:
tcg: tcg-op.h
Log message:
32-bit host sign extension fix (Juergen Lock).
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot
On Wednesday 27 February 2008, Andreas Färber wrote:
> Am 27.02.2008 um 17:14 schrieb Paul Brook:
> >> I still have problems (Pentium M, gcc (GCC) 4.1.2 20061115
> >> (prerelease)
> >
> > gcc4 isn't supposed to work.
>
> And I thought that was the wh
> I still have problems (Pentium M, gcc (GCC) 4.1.2 20061115 (prerelease)
gcc4 isn't supposed to work.
Paul
On Monday 25 February 2008, Rob Landley wrote:
> On Tuesday 08 January 2008 09:22:49 Alexander Graf wrote:
> > Apples hardware dongle sits withing the fan control. To get Mac OS X up
> > and running, this control device needs to be emulated and given the
> > correct dongle key. This key has to be g
> Another point is that you should define TCG globals for each SPARC GPR.
> It was not done for i386 because I feared performance regressions when
> accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have
> this issue.
How would these be kept consistent with CPUState?
Paul
> I'm not really familiar with the qemu development process; is this
> usually how it works? People are free to break things and assume others
> will fix it?
Not really. However this is fairly exceptional circumstances. The gcc3
dependency means it's getting harder and harder to build qemu at al
On Thursday 21 February 2008, Jerone Young wrote:
> The recent TCG code to replace dyngen code in qemu cvs has broken
> PowerPC host support (or from what is appears...anyone else who is not
> x86 or x86-64). Is anyone working to fix this ? Is there a plan to fix
> all the other hosts?
As far as p
On Thursday 21 February 2008, Arabinda Verma wrote:
> Hello Paul,
>
> Thanks for your reply.
>
> Please recommend some document or pointer on how to implement emulation of
> hardware.
Theere isn't any, just what's in the source. It's mostly fairly
straightforward once you get your head round it.
> Is savevm-upon-disk-full a realistic prospect?
Not particularly useful. If you're run out of disk space, chances are that
savevm will also fail.
Paul
> Write errors for non-raw formats can easily be caused by a disk full
> situation on the host. Killing the guest hard is unfriendly for that
> situation.
Disk full is a fundamentally unfriendly situation to be in. There is no good
answer. Reporting errors back to the host has its own set of pro
> > Finally, it would perhaps be best if the block device emulators wrote
> > to the qemu console to complain if they give write errors. Otherwise
> > the errno value and other important information will be lost, which
> > makes debugging hard.
>
> If by 'qemu console' you mean stderr, then fine,
> SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I
> don't think anything other than Linux runs in QEMU's Sun emulation (or
> for that matter, any of the non-PC QEMU emulators).
While linux is certainly the most most widely tested, I'm fairly sure both
vxWorks and SymbianOS h
On Saturday 16 February 2008, Christian Roue wrote:
> Hi all,
> I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 using
> --disable-gcc-check, I found compile fails as stated in configure before i
> disabled gcc check..
> Error message, points to a problem of dyngen not correctly d
> If people don't like using environmental variables, I can accept that.
> Let's not pretend though that the reason is that we're protecting the
> end users :-)
It's more protecting me from end users :-)
I should have said part of the reason. I'll admit a large part is personal
preference.
Paul
> I think Paul Brook was concerned about a situation where a user
> reports a problem saying FOO is not working when running "qemu -hda ..."
> and suddenly the number of things that may have triggered the bug has
> grown by the size of the environment. Even if you manage
> > Any news on the possible cvs->svn migration?
>
> To be perfectly honest, IMO there is little point moving an existing
> project from CVS to SVN.
I disagree. CVS has several fairly fundamental flaws (no global revision IDs,
unable to move files, and more subtle problems with branches/tags).
S
On Tuesday 12 February 2008, Rob Landley wrote:
> On Saturday 19 January 2008 15:10:09 Paul Brook wrote:
> > > In the absence of a global configuration file, a reasonably sane way to
> > > support this configuration system wide is to use an environmental
> > > variabl
On Sunday 10 February 2008, Avi Kivity wrote:
> Paul Brook wrote:
> >>> as far as i remember it was used to address something with
> >>> cpu_physical_memory_rw() probably related to &TARGET_PAGE_SIZE
> >>> or ~TARGET_PAGE_SIZE,
> >>>
>
> > as far as i remember it was used to address something with
> > cpu_physical_memory_rw() probably related to &TARGET_PAGE_SIZE
> > or ~TARGET_PAGE_SIZE,
> >
> > the fact is that i dont know if it ever fixed anything
>
> It fixes TARGET_PAGE_MASK, defined one line downscreen.
That doesn't reall
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/10 14:09:09
Modified files:
. : translate-all.c
tcg: tcg.c tcg.h
tcg/i386 : tcg-target.c
tcg/x86_64 : tcg-target.c
Log message
On Sunday 10 February 2008, Blue Swirl wrote:
> On 2/9/08, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Blue Swirl wrote:
> > >> If you look at the patch, there are no timing dependencies; the only
> > >> parameter is the depth of the virtual queue. The exhaustion is
> > >> completely controlled
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/10 02:41:15
Modified files:
. : translate-all.c
tcg: tcg.c tcg.h
Log message:
Fix TCG relocation bug (exposed by fault after brcond op). Add FIXME
for
On Friday 08 February 2008, Blue Swirl wrote:
> On 2/8/08, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > The patch takes a half of the memory and slows down the system. I
> > > think Qemu could be used instead. A channel (IO/MMIO) is created
> > > between the m
> The patch takes a half of the memory and slows down the system. I
> think Qemu could be used instead. A channel (IO/MMIO) is created
> between the memory allocator in target kernel and Qemu running in the
> host. Memory allocator tells the allocated area to Qemu using the
> channel. Qemu changes
On Friday 08 February 2008, Rob Landley wrote:
> Grepping through the source code, I can find 3 places where this global
> variable is set (it's initialized to a default value of 1, there's
> a "no-code-copy" command line option that sets it to zero, and then it
> shows up in the test suite once).
On Wednesday 06 February 2008, Jamie Lokier wrote:
> Paul Brook wrote:
> > > > but make
> > > > it configurable on the command line. That way, there are no
> > > > surprises ever. The rare people like me with an issue can just pass
> > > > a com
> > but make
> > it configurable on the command line. That way, there are no surprises
> > ever. The rare people like me with an issue can just pass a command-line
> > parameter in.
>
> The point I was trying to make is that qemu could easily arbitrate the
> guest network based on how the host is
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/03 19:56:34
Modified files:
target-i386: translate.c
tcg: tcg-op.h tcg.c tcg.h
Log message:
Add TCG variable opaque type.
CVSWeb URLs:
http://cvs.savannah.gnu.org
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/03 19:20:13
Modified files:
. : configure
Log message:
Robustify source directory check.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/03 17:35:41
Modified files:
. : exec-all.h
Log message:
Fix opparam_buf size estimate.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemu&r1=1.7
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/03 16:27:13
Modified files:
. : configure
Log message:
Use ARCH_CFLAGS in configure tests.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1
> I made minimal modifications in each target so that they can still work
> by using TCG and legacy "dyngen" micro operations. More work will be
> needed to convert each target to TCG, but it can be done progressively.
> Only the x86 and x86_64 targets have been significantly modified to use
> TCG.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/01 22:45:05
Modified files:
. : Makefile.target
Log message:
Add missing dependencies on generated files (for parallel build).
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs
> virtio could still be made to work with map cache. You would just have
> to change it to be able to map more than one page contiguously. As I
> mentioned though, it just starts getting ugly.
That's why you should be using the cpu_physical_memory_rw routines :-)
Anything that assume large line
On Friday 01 February 2008, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 1 Feb 2008, Christian Laursen wrote:
> > Gervase Lam <[EMAIL PROTECTED]> writes:
> > >>>From my minimal understanding of what he is saying, it seems he would
> > >
> > > prefer there to be a BOCHS graphics adapter, which would
> > I agree with the fact that ram_size should be 64 bit. Maybe each
> > machine could test the value and emit an error message if it is too
> > big. Maybe an uint64_t would be better though.
>
> uint64_t is probably more reasonable. I wouldn't begin to know what the
> appropriate amount of ram wa
> > Are the CMOS contents documented anywhere?
>
> No, but if you have a suggestion of where to document them, I'll add
> documentation.
I suggest in or with the BIOS sources.
As we're using a common BIOS it seems a good idea to make sure this kind of
things is coordinated.
Paul
> >> +#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
> >
> > This seems fairly arbitrary. Why? Any limit is certainly target specific.
>
> On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
> in virtual address space. On a 64-bit host, there isn't this
> fundamental
> -cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
> +cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);
smp_cpus is a global variable. Why bother passing it around?
Are the CMOS contents documented anywhere?
Paul
On Thursday 31 January 2008, Anthony Liguori wrote:
> KVM supports more than 2GB of memory for x86_64 hosts. The following patch
> fixes a number of type related issues where int's were being used when they
> shouldn't have been. It also introduces CMOS support so the BIOS can build
> the appropr
> Is this a reasonable merge strategy? We won't introduce regressions but
> I can't guarantee these new things will work cross-architecture.
I think it depends to some extent whether things will need rewriting to be
made cross-architecture. In particular if this requires interface changes.
Thi
> > Why don't you just put your custom flags in CFLAGS, not CPPFLAGS?
> > The former is deliberately left for the user to override.
>
> Several (but not all AFAICT) of the target subdirectory Makefiles set
> CFLAGS.
Really? Which ones?
Paul
> Providing a definition in config-host.mak involves duplicating the
> value, which can't be right.
Huh? No it doesn't. config-host.mak contains
CPPFLAGS=
then Makefile.target contains
CPPFLAGS+=whatever
> If there's no other way to do it then
> there should be a reference to USER_CPPFLAGS or
On Friday 25 January 2008, Ian Jackson wrote:
> Paul Brook writes ("Re: [Qemu-devel] [PATCH] CPPFLAGS+= in
Makefile.target"):
> > In that case you should always provide a definition in config-host.mak.
> > Under some circumstances make may inherit initial values
> What I mean is: if you want
> for any reason to build qemu in a weird way then you're going to have
> to edit config-host.mak (or somewhere similar) in any case. You
> probably want to set some CPPFLAGS as well as various other things.
> If you do this at the moment then you have to reproduce al
> Saying CPPFLAGS+= is much more convenient if for any reason the
> external build environment would like to pass unusual CPPFLAGS.
No. This doesn't do what you thing it does.
The most common way of overriding these variables is to pass them on the
commandline, i.e. "make CPPFLAGS=-blah". This ov
On Monday 21 January 2008, C.W. Betts wrote:
> I was thinking, maybe qemu could use threads for at least every processor
> it emulates (on emulated smp computers) and, at the most, every single
> device emulated. This would help users who have multiple cores, but it
> might impact performance on t
> Well, what about adding a new backend phase to gcc generating what we
> expect for our purpose? Ok, it is rather easy to have a branch in gcc,
> harder to have it accepted in the main-stream gcc... :-) With a good
> argumentation...
IMHO (as a full time gcc developer) it's easier to just impleme
On Sunday 20 January 2008, Filip Navara wrote:
> Hello,
>
> attached is a patch that implements the SMBIOS within the Bochs BIOS code.
> Complete list of changes:
This should be submitted to the Bochs list.
Paul
> In the absence of a global configuration file, a reasonably sane way to
> support this configuration system wide is to use an environmental
> variable. QEMU already uses a number of global variables for
> configuring audio options.
I'd really prefer we didn't do this, and preferably obsoleted/r
> the next step would be to emulate LSI SCSI chips, eh?
Qemu already does.
Paul
601 - 700 of 1782 matches
Mail list logo
