There's no need to call into ->parse and ->print manually.  The
QOM legacy properties do that for us.

Furthermore, in some cases legacy and static properties have exactly
the same behavior, and we could drop the legacy properties right away.
Add an appropriate fallback to prepare for this.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This is mostly code movement although not entirely.  This makes properties part
of the Object base class which means that we can now start using Object in a
meaningful way outside of qdev.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

I'm sure the intentions were good here, but there's no reason this should be in
qdev.  Move it to qemu-char where it belongs.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

qdev-monitor.c deals with the -device, device_add, and info qdm/qtree
interfaces.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Note that the FIXME gets fixed in series 4/4.  We need to convert BusState to
QOM before we can make parent_bus a link.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This gets us closer to being able to object_new() a qdev type and have a
functioning object verses having to call qdev_create().
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Limit them to the device_add functionality.  Device aliases were a hack based
on the fact that virtio was modeled the wrong way.  The mechanism for aliasing
is very limited in that only one alias can exist for any device.

We have to support it for the purposes of compatibility but we only need to
support it in device_add so restrict it to that piece of code.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
---
v1 -> v2
 - Use a table for aliases (Paolo)

It is no longer used in the tree since everything is done natively through
QEMU Object Model.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Teach the various bits of code that need to walk through available devices to
do so via QOM.

Signed-off-by: Anthony Liguori

As we use class_init to set class members, DeviceInfo no longer holds this
information.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This allows us to drop per-Device registration functions by allowing the
class_init functions to overload qdev methods.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Now DeviceInfo is no longer used after object construction.  All of the
relevant members have been moved to DeviceClass.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Introduce accessors and remove any code that directly accesses DeviceInfo
members.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Since we are still dynamically creating TypeInfo, we need to chain the
class_init function in order to be able to make use of it within subclasses of
TYPE_DEVICE.

This will disappear once we register TypeInfos directly.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

In order to introduce inheritance while still using the qdev registration
interfaces, we need to be able to use a parent other than TYPE_DEVICE.  Add a
new interface that allows this.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We already have a QOM interface for this so let's use it.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Right now, DeviceInfo acts as the class for qdev.  In order to switch to a
proper ObjectClass derivative, we need to ween all of the callers off of
interacting directly with the info pointer.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This is a very shallow integration.  We register a TYPE_DEVICE but only use
QOM as basically a memory allocator.  This will make all devices show up as
QOM objects but they will all carry the TYPE_DEVICE.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
---
v1 -> v2
 - update for new location of object.h

Improve VGA selection logic, push check for device availabilty to vl.c.
Create the devices at board level unconditionally.

Remove now unused pci_try_create*() functions.

Make PCI VGA devices optional.
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Commit 8eb02831 broken device_del by having too overzealous reference counting
checks.  Move the reference count checks to qdev_free(), make sure to remove
the parent link on free, and decrement the reference count on property removal.
Reported-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The peripheral[-anon] containers are initialized lazily but since they sit on
sysbus, they can not be created after realize.  This was causing an abort() to
occur during hotplug if no -device option was used.

This was spotted by qemu-test::device-add.sh
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Push legacy properties into a "legacy-..." namespace, and make them
available with correct types too.

For now, all properties come in both variants.  This need not be the
case for string properties.  We will revisit this after -device is
changed to actually use the legacy properties.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

qdev_property_get and qdev_property_set can generate permission
denied errors themselves.  Do not duplicate this functionality in
qdev_get/set_legacy_property, and clean up excessive indentation.
Reviewed-by: NAnthony Liguori <anthony@codemonkey.ws>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Reviewed-by: NAnthony Liguori <anthony@codemonkey.ws>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The full tree search was a bit unreasonable.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We first add a 'peripheral' container to the root device that we add user
created devices to.  This provides all user created devices with a unique and
isolated namespace.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Links represent an ephemeral relationship between devices.  They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.

Links are fairly limited in their usefulness without implementing QOM-style
subclassing and interfaces.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Child properties express a relationship of composition.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

There are two types of supported paths--absolute paths and partial paths.

Absolute paths are derived from the root device and can follow child<> or
link<> properties.  Since they can follow link<> properties, they can be
arbitrarily long.  Absolute paths look like absolute filenames and are prefixed
with a leading slash.

Partial paths are look like relative filenames.  They do not begin with a
prefix.  The matching rules for partial paths are subtle but designed to make
specifying devices easy.  At each level of the composition tree, the partial
path is matched as an absolute path.  The first match is not returned.  At
least two matches are searched for.  A successful result is only returned if
only one match is founded.  If more than one match is found, a flag is returned
to indicate that the match was ambiguous.

At the end of the day, partial path support means that if you create a device
called 'ide0', you can just say 'ide0' as the path name and it will Just Work.
If we internally create a device called 'i440fx', you can just say 'i440fx' and
it will Just Work and long as you don't do anything silly.

A management tool should probably always use absolute paths since then they
don't have to deal with the possibility of ambiguity.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The canonical path is the path in the composition tree from the root to the
device.  This is effectively the name of the device.

This is an incredibly unefficient implementation that will be optimized in
a future patch.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This is based on Jan's suggestion for how to do unique naming.  The root device
is the root of composition.  All devices are reachable via child<> links from
this device.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Expose all legacy properties through the new QOM property mechanism.  The qdev
property types are exposed through the 'legacy<>' namespace.  They are always
visited as strings since they do their own string parsing.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>