svn commit: r314862 - head/sys/modules/qlxgbe

Gleb Smirnoff glebius at FreeBSD.org
Wed Mar 8 22:39:10 UTC 2017


On Wed, Mar 08, 2017 at 01:57:32PM -0800, Ngie Cooper (yaneurabeya) wrote:
N> > On Wed, Mar 08, 2017 at 01:00:30AM +0200, Andriy Gapon wrote:
N> > A> On 08/03/2017 00:17, Gleb Smirnoff wrote:
N> > A> > On Tue, Mar 07, 2017 at 03:43:49PM +0000, Andriy Gapon wrote:
N> > A> > A> Author: avg
N> > A> > A> Date: Tue Mar  7 15:43:49 2017
N> > A> > A> New Revision: 314862
N> > A> > A> URL: https://svnweb.freebsd.org/changeset/base/314862
N> > A> > A>
N> > A> > A> Log:
N> > A> > A>   qlxgbe: add GCC_MS_EXTENSIONS to CFLAGS to make old base GCC happy
N> > A> > A>
N> > A> > A>   The module uses unnamed structure and union fields and base GCC in
N> > A> > A>   stable/10 doesn't like it.
N> > A> > A>   I think that that is a C11 feature, so it is courteous of more modern
N> > A> > A>   compilers to not complain about it when compiling in C99 mode.
N> > A> >
N> > A> > There are a lot of code in kernel, that uses anonymous structs and unions.
N> > A> > This feature is enabled globally. Why does this module need special treatment?
N> > A>
N> > A> That's a good question and I don't have a good answer to it.
N> > A> All I can say is that a GCC build of GENERIC and modules failed in that fashion
N> > A> only for this module (in stable/10).
N> > A> Maybe I described the problem incorrectly.  Then, a proper explanation is welcome.
N> > 
N> > In head this is fixed properly:
N> > 
N> > https://svnweb.freebsd.org/base?view=revision&revision=278913
N> > 
N> > Can you please move your fix to stable/10 and revert it in head?
N> 
N> I understand there might be conflicts, but wouldn’t it be better to revert and MFC the change you committed to ^/head (which is already in ^/stable/11) to ^/stable/10?

Could be. But I intentionally avoided MFCing it back in 2015, in my humble
opinion changing global compilation flags is something not for a stable
branch. I defintely won't go for it, but anybody else welcome :)

-- 
Totus tuus, Glebius.


More information about the svn-src-head mailing list