On Tue, Feb 25, 2014 at 10:24:30AM +0100, Romain Dolbeau wrote:
> 2014-02-25 9:58 GMT+01:00 Romain Dolbeau <rom...@dolbeau.org>:
>
> > 2014-02-25 9:01 GMT+01:00 Andreas Färber <afaer...@suse.de>:
> >
> > > @@ -1572,6 +1572,9 @@ static const char * const pci_nic_models[] = {
> >> > @@ -1584,6 +1587,9 @@ static const char * const pci_nic_names[] = {
> >>
> >> I would hope that adding to these two legacy lists is not necessary for
> >> new types. They should be created using -device, not -net nic,model=.
> >>
> >
> > Again I don't understand - I took inspiration from eepro100.c, and it has
> > 3 devices in there
> > (i82551, i82557b, i82559er). And the model is handled by -device, as my
> > example
> > shows:
> > #####
> > "-netdev user,id=mynet0 -device 82545EM,netdev=mynet0"
> > #####
> >
> > I was misled by the presence of "e1000" and several eepro100 variants in
> this list.
> Modifying it is not necessary, it works fine without it. I suppose that's
> what you
> meant - that it works both ways (-device or -net nic), but the second
> option is not
> required for new device as it's a deprecated way of doing things?
Hi Romain,
First of all, thanks for doing this work. There have been requests to
expose additional e1000-family NIC models from users before. They were
running guests with drivers that didn't recognize the default e1000.
About Andreas' comments: QEMU Object Model (QOM) is the newer
infrastructure for defining device classes in QEMU. Previously qdev was
used (and that typically involved DO_UPCAST()).
A lot of the qdev code is actually still around. Some of it has been
rewritten to use QOM. This can sometimes make it hard to understand
what is the "modern" way of doing things.
QOM is an object-oriented model where you can define class hierarchies.
By defining a base class, you can make all the e1000 NIC types support
the same parent e1000 type.
So in C++/Java/C# this would be something like:
class E1000Base { ... }
class 82540EM : public E1000Base { ... };
That way you can refer to all e1000-based NICs by their E1000Base type
without DO_UPCAST() or explicit C type casting.
I think the example that Andreas was referring to is closer to
hw/block/m25p80.c:
static const TypeInfo m25p80_info = {
.name = TYPE_M25P80,
.parent = TYPE_SSI_SLAVE,
.instance_size = sizeof(Flash),
.class_size = sizeof(M25P80Class),
.abstract = true,
};
static void m25p80_register_types(void)
{
int i;
type_register_static(&m25p80_info);
for (i = 0; i < ARRAY_SIZE(known_devices); ++i) {
TypeInfo ti = {
.name = known_devices[i].part_name,
.parent = TYPE_M25P80,
.class_init = m25p80_class_init,
.class_data = (void *)&known_devices[i],
};
type_register(&ti);
}
}
m25p80_info defines an abstract base class. It cannot be instantiated
but it serves as the parent type for all M25P80 devices.
Does this help?
Stefan
