lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a2d2e457-47e5-bb73-a059-0cb907a29ae0@synopsys.com>
Date:   Thu, 12 Jan 2017 09:43:03 +0000
From:   Joao Pinto <Joao.Pinto@...opsys.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Joao Pinto <Joao.Pinto@...opsys.com>, <davem@...emloft.net>
CC:     <lars.persson@...s.com>, <niklass@...s.com>,
        <peppe.cavallaro@...com>, <alexandre.torgue@...com>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] stmmac: rename it to synopsys


Hi Florian,

Às 9:14 PM de 1/11/2017, Florian Fainelli escreveu:
> On 01/10/2017 06:52 AM, Joao Pinto wrote:
>> This patch renames stmicro/stmmac to synopsys/ since it is a standard
>> ethernet software package regarding synopsys ethernet controllers, supporting
>> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
>> retro-compatibility, only the description was changed.
> 
> Do re really have to do this? ST Micro were the first to upstream
> support for a Synopsys IP, and it was later on identified as being
> "stmicro" instead of "synopsys" (during the big driver move under
> drivers/net/ethernet) whichever came first in the driver essentially "wins".
> 
> As mentioned before, although git is able to track renames, git log does
> not automatically have --follow, so it can be hard for people to track
> down the (new) history of the driver.
> 
> Personally, I don't see much value in doing this rename, especially when
> all the driver internal structures are still going to be named with
> stmmac (and please don't even think about doing a s/stmmac/snps/ inside
> the driver ;)).
> 
> My 2 cents.
> 

First of all, I am suggesting an alternative way of organizing the code, and
that's it, I have no second intentions about anything :).

Please don't see this as a take-over or erase Stmicro from credits, please... it
makes no sense. You can leave STMicro license and all the credits fine by me and
I insist on it. But lets name it for something that makes sense... lets call it
dwc (designware controllers), I am totally open to suggestions.

I don't understand the hostility of some comments, honestly.

The easiest way is to keep things like they are today, and believe me I have a
lot of things to do, like adding the support of multi-queues / multi-channels to
stmmac, so I not suggesting this because it is fun.

I am suggesting this because it is what I am used to seeing in other subsystems.
USB has dwc2 and dwc3 folders that clearly identifies that they are Designware
(synopsys) extensions to the USB 2.0 and 3.0. The author of dwc3 was Texas
Instruments, and they did not name it ti/usb. For example I use an AXS101
Development board that does not have a stmicro SoC but has a Designware Ethernet
IP in it, so uses stmicro/stmmac. For me it is confusing.

Lets not name it synopsys, for me it is totally fine, but naming it
stmicro/stmmac is not the right way because it seems like it is a driver just
for stmicro products, which is not, is for products that use Designware Ethernet
IPs.

I am volunteering to do this work, let's discuss this.

Thanks,
Joao


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ