qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] e1000: add the ability to select among several


From: Romain Dolbeau
Subject: Re: [Qemu-devel] [PATCH] e1000: add the ability to select among several specific types of e1000, plus some pointers to documentations and details.
Date: Tue, 25 Feb 2014 09:58:10 +0100

2014-02-25 9:01 GMT+01:00 Andreas Färber <address@hidden>:
> -#define E1000(obj) \
> -    OBJECT_CHECK(E1000State, (obj), TYPE_E1000)
> +#define E1000(obj)                              \
> +  DO_UPCAST(E1000State, parent_obj, obj)

No, don't go backwards in time please. Take a look at e.g. eepro100,
which already registers multiple data-driven subtypes for instance. The
key to making it work is to introduce an abstract base type matching
E1000() macro, with original "e1000" type becoming a subtype thereof.

I don't understand. I did look at "eepro100.c", it does exactly the same thing
in the init() and uninit() (where E1000() is used):
#####
static int e100_nic_init(PCIDevice *pci_dev)
{
    EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
#####

> @@ -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"
#####

Cordially,

--
Romain Dolbeau

reply via email to

[Prev in Thread] Current Thread [Next in Thread]