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

[Ngie Cooper]

> On Mar 8, 2017, at 14:39, Gleb Smirnoff <glebius at FreeBSD.org> wrote:
> 
> 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 :)

Looking at the number of changed makefilea/drivers again, I agree with your discretion, but I do wonder if some of the failures on ^/stable/10 are caused by this lack of support (on 2nd tier platforms like arm). It makes it ever so important for people backporting changes to be careful...

Also, any changes avg@ makes should be backported to ^/stable9 because the driver was backported there (and because clang isn't in the source tree there IIRC -- I don't remember exactly since I haven't used 9.x for 6+ months).

Thanks,
-Ngie