netdev - Re: [PATCHv3 net-next 00/31] Misc. fixes for cxgb4 and iw

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]

Date:	Wed, 5 Mar 2014 11:46:22 -0800
From:	Casey Leedom <leedom@...lsio.com>
To:	Or Gerlitz <or.gerlitz@...il.com>
Cc:	Hariprasad S <hariprasad@...lsio.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	linux-rdma <linux-rdma@...r.kernel.org>,
	Roland Dreier <roland@...estorage.com>, kumaras@...lsio.com,
	dm@...lsio.com, Steve Wise <swise@...ngridcomputing.com>,
	santosh@...lsio.com, nirranjan@...lsio.com
Subject: Re: [PATCHv3 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4

On Mar 5, 2014, at 11:39 AM, Or Gerlitz <or.gerlitz@...il.com> wrote:

> On Wed, Mar 5, 2014 at 9:15 PM, Casey Leedom <leedom@...lsio.com> wrote:
>>  Yes, thanks mightily for your help and advice and sorry for the size of the updates.  Hari has taken on the very difficult task of synchronizing our out-of-kernel development branch with the in-kernel code.  These two code bases have drifted apart quite a bit because of the difficulty of translating our out-of-kernel changes into the in-kernel driver which uses completely different symbolic register constants.
> 
> Can you explain this in a little bit more details? what's the source
> of the need to use two different sets of symbolic register constants?

  When our cxgb4 driver was first submitted for inclusion in kernel.org someone objected to the format of our symbolic register constants and forced us to change them.  Unfortunately these constants are generated directly from our hardware design and we can’t change them internally — it would significantly increase development/debugging time with our hardware team if we had to constantly help the hardware team member translate back and forth between the confusingly similar but different names.  Additionally, though I know that this isn’t a concern of kernel.org, every other OS driver for our adapters use the hardware-derived symbolic register constants and our software team internally often work on several different OS Drivers as we work out better ways to do various things.  All of this means that our in-house/out-of-kernel driver uses the hardware-derived symbolic constants and every time we need to push a change into kernel.org we need to go through a very careful translation of the symbolic register constants.

Casey

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html