[Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[Markus Armbruster]

Commit 79ca616 "pci: Cleanup configuration for pci-hotplug.c" (June
2013, released in v1.6.0) made linking pci-hotplug-old.o conditional on
make variable CONFIG_PCI_HOTPLUG_OLD, and the actual monitor commands
conditional on preprocessor macro CONFIG_PCI_HOTPLUG_OLD.  Where is that
macro defined?

In my local build: nowhere.  The two commands are not available.

Am I doing something wrong, or have the commands been gone for five
major releases already?

If the latter, I think we can safely drop them now :)

Re: [Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

On Fri, Feb 13, 2015 at 05:51:26PM +0100, Markus Armbruster wrote:
> Commit 79ca616 "pci: Cleanup configuration for pci-hotplug.c" (June
> 2013, released in v1.6.0) made linking pci-hotplug-old.o conditional on
> make variable CONFIG_PCI_HOTPLUG_OLD, and the actual monitor commands
> conditional on preprocessor macro CONFIG_PCI_HOTPLUG_OLD.  Where is that
> macro defined?
> 
> In my local build: nowhere.  The two commands are not available.
> 
> Am I doing something wrong, or have the commands been gone for five
> major releases already?
> 
> If the latter, I think we can safely drop them now :)

So AFAICT, CONFIG_PCI_HOTPLUG_OLD is still defined for x86 targets:

$ git grep PCI_HOTPLUG_OLD
default-configs/i386-softmmu.mak:CONFIG_PCI_HOTPLUG_OLD=y
default-configs/x86_64-softmmu.mak:CONFIG_PCI_HOTPLUG_OLD=y
...

I believe the reasoning was that for other targets, pci_add/del were
never properly supported and we should go directly to device_add/del
instead.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[Paolo Bonzini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 13/02/2015 23:54, David Gibson wrote:
> So AFAICT, CONFIG_PCI_HOTPLUG_OLD is still defined for x86
> targets:
> 
> $ git grep PCI_HOTPLUG_OLD 
> default-configs/i386-softmmu.mak:CONFIG_PCI_HOTPLUG_OLD=y 
> default-configs/x86_64-softmmu.mak:CONFIG_PCI_HOTPLUG_OLD=y ...

But these symbols do not become preprocessor macros...

Paolo

Re: [Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Sat, Feb 14, 2015 at 02:19:43PM +0100, Paolo Bonzini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> On 13/02/2015 23:54, David Gibson wrote:
> > So AFAICT, CONFIG_PCI_HOTPLUG_OLD is still defined for x86
> > targets:
> > 
> > $ git grep PCI_HOTPLUG_OLD 
> > default-configs/i386-softmmu.mak:CONFIG_PCI_HOTPLUG_OLD=y 
> > default-configs/x86_64-softmmu.mak:CONFIG_PCI_HOTPLUG_OLD=y ...
> 
> But these symbols do not become preprocessor macros...

Godammit.  Have I mentioned lately how much it pisses me off that we
have various config symbols and it's never clear which ones make it
into C and which are only in make.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[Peter Maydell]

On 15 February 2015 at 03:02, David Gibson <david@gibson.dropbear.id.au> wrote:
> Godammit.  Have I mentioned lately how much it pisses me off that we
> have various config symbols and it's never clear which ones make it
> into C and which are only in make.

That does seem confusing. Is there a reason we can't have a
config-devices.h which gets created from config-devices.mak?

-- PMM

Re: [Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 15 February 2015 at 03:02, David Gibson <david@gibson.dropbear.id.au> wrote:
>> Godammit.  Have I mentioned lately how much it pisses me off that we
>> have various config symbols and it's never clear which ones make it
>> into C and which are only in make.
>
> That does seem confusing. Is there a reason we can't have a
> config-devices.h which gets created from config-devices.mak?

Newsflash: homespun configuration system confusing, film at eleven.

(Autoconf is also confusing, but at least it's the same confusion
everywhere)

Back to serious: patching configure to make sure all the CONFIG_ make
variables make it into header files sounds good to me.

With #ifdef tests, forgetting to include the header switches things off.
A single header makes guarding against that mistake easier: every .c
needs to include it first, check with grep.

Re: [Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[Paolo Bonzini]

On 15/02/2015 12:12, Peter Maydell wrote:
> On 15 February 2015 at 03:02, David Gibson <david@gibson.dropbear.id.au> wrote:
>> Godammit.  Have I mentioned lately how much it pisses me off that we
>> have various config symbols and it's never clear which ones make it
>> into C and which are only in make.
> 
> That does seem confusing. Is there a reason we can't have a
> config-devices.h which gets created from config-devices.mak?

Blue Swirl opposed it because we already had qdev_try_create...  The
problem here was that CONFIG_PCI_HOTPLUG_OLD was in config-devices.mak
but not a device.  There were other cases before (CONFIG_FDT maybe?) but
I think this was the last one.

I'd just kill it at this point...

Paolo

Re: [Qemu-devel] Did we lose monitor commands pci_add, pci_del?

[Michael Tokarev]

16.02.2015 10:57, Markus Armbruster wrote:
[]
> Back to serious: patching configure to make sure all the CONFIG_ make
> variables make it into header files sounds good to me.
> 
> With #ifdef tests, forgetting to include the header switches things off.
> A single header makes guarding against that mistake easier: every .c
> needs to include it first, check with grep.

Single header means that any change in config options results in
recompilation of everything.  Linux kernel solves this but the
mechanism is a bit heavy...

Thanks,

/mjt