From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id C0B045A8A for ; Tue, 14 Apr 2015 16:30:23 +0200 (CEST) Received: by wgyo15 with SMTP id o15so14154849wgy.2 for ; Tue, 14 Apr 2015 07:30:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CqN33f/aRyvo9nJPK5uMA4XwwkV4M2zPOCddPXoK6BE=; b=Il19NQLBcZJWS9UVShM/CrSWzADNNxKI30jwkVSmhaULXm7hv6yrGzPN6HuJaJ5v8t U6YIsRWPRewXmw3vQvCz7iYuRIdMF4wa54JLLcXyIu6mjKCJWjXacnblh5HaOFbZa/5E UX0b1u72pRk9ngR6w7IPKZxVBZxDAqOPQEnkptPnYc080ZxPzXssrR7Ys0dd9RZKsg2/ w88fA4iu8Vn2pwnLKKvF6kMLY4RGnjF3sFknVz9dHL7vU6G6Fqt8vFq+vk6isxjTeYdi SynTkWHsaRsqR2yY3MwFd4nubRtKxky9IjfWcsb2VfuKVW2jXT+Mbagc+jNhdWHDxa91 C/bQ== X-Gm-Message-State: ALoCoQknhpPld0y+dtWt1bEfcniCjtpdPnVpQ+Ju6+n4VJLxgsqs16PmhSD+87yNDwU0B6v0tToY X-Received: by 10.180.93.166 with SMTP id cv6mr32332605wib.89.1429021823645; Tue, 14 Apr 2015 07:30:23 -0700 (PDT) Received: from [10.0.0.166] ([212.143.139.214]) by mx.google.com with ESMTPSA id f8sm3062036wiy.7.2015.04.14.07.30.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 07:30:23 -0700 (PDT) Message-ID: <552D247D.9040204@cloudius-systems.com> Date: Tue, 14 Apr 2015 17:30:21 +0300 From: Vlad Zolotarov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Thomas Monjalon References: <1429003900-20074-1-git-send-email-thomas.monjalon@6wind.com> <2601191342CEEE43887BDE71AB9772582141570C@irsmsx105.ger.corp.intel.com> <552D1869.4060703@cloudius-systems.com> <54963304.brPH8sEe9A@xps13> In-Reply-To: <54963304.brPH8sEe9A@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix build with gcc 4.4 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:30:24 -0000 On 04/14/15 17:17, Thomas Monjalon wrote: > 2015-04-14 16:38, Vlad Zolotarov: >> On 04/14/15 16:06, Ananyev, Konstantin wrote: >>> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] >>>> On 04/14/15 12:31, Thomas Monjalon wrote: >>>>> - struct rte_eth_dev_info dev_info = { 0 }; >>>>> + struct rte_eth_dev_info dev_info = { .max_rx_queues = 0 }; >>>> Hmmm... Unless I miss something this and one above would zero only a >>>> single field - "max_rx_queues"; and would leave the rest uninitialized. >>>> The original code intend to zero the whole struct. The alternative to >>>> the original lines could be usage of memset(). >>> As I understand, in that case compiler had to set all non-explicitly initialised members to 0. >>> So I think we are ok here. >> Yeah, I guess it does zero-initializes the rest >> (https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html) however I >> don't understand how the above change fixes the error if it complains >> about the dev_info.driver_name? > As only 1 field is required, I chose the one which should not be removed > from this structure in the future. I don't follow - where/why only one field is required? The function u are patching uses "rx_offload_capa" field. Or u mean this gcc version requires only one field? If so, could u, please, provide the errata u are referring, since standard doesn't require any field and {0} is an absolutely legal (and proper) initializer in this case... > >> What I'm trying to say - the proposed fix is completely unclear and >> confusing. Think of somebody reading this line in a month from today - >> he wouldn't get a clue why is it there, why to explicitly set >> max_rx_queues to zero and leave the rest be zeroed automatically... Why >> to add such artifacts to the code instead of just zeroing the struct >> with a memset() and putting a good clear comment above it explaining why >> we use a memset() and not and initializer? > We can make it longer yes. > I think you agree we should avoid extra lines if not needed. > In this case, when reading "= { .field = 0 }", it seems clear our goal > is to zero the structure (it is to me). > I thought it is a basic C practice. > > You should try "git grep '\.[^ ]\+ *= *0 *}'" to be convinced that we are > not going to comment each occurence of this coding style. > But it must be explained in the coding style document. Agree?