qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 7/8] Add ENET/Gbps Ethernet support to FEC de


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v4 7/8] Add ENET/Gbps Ethernet support to FEC device
Date: Thu, 19 May 2016 19:37:43 +0100

On 19 May 2016 at 19:14, Jean-Christophe DUBOIS <address@hidden> wrote:
> Le 19/05/2016 05:48, Jason Wang a écrit :
>> On 2016年05月19日 06:23, Jean-Christophe Dubois wrote:
>>
>> It's ok to decide with "is-fec", but is it better to use a new type for
>> that?
>
>
> Well, there is a lot of common code between FEC and ENET because ENET is
> basically backward compatible with FEC. So most/all of the FEC code needs to
> go in the ENET device.
>
> I thought this way of doing thing was the best way to avoid duplicating
> things.

Right, but usually we have different device types, even if under
the hood it's the same code using a bool to decide what to do
(see for instance hw/display/pl110.c, which provides 3 devices
which are all pretty similar). This means that the users of your
device don't need to care that the FEC is an ENET device with
a flag to say "be like an FEC device", they just instantiate
the kind of device they want.

>> The above renaming seems cause lots of unnecessary changes above which may
>> brings issue when backporint patches to -stable. Can we just keep this, and
>> all ENET_*** should be used after we're sure we are ENET?
>
>
> What do you mean by "after we're sure we are ENET"?
>
> ENET is the evolution of FEC to support Gb interface. FEC is more like a
> legacy device these days (for ARM9 family). So it seems we are better
> supporting ENET as default going forward.

I don't mind if we rename the functions, #defines, etc, but if
we do can we have a patch which does that renaming and only that
renaming, so it's easy to review?

thanks
-- PMM



reply via email to

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