From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id E89805A26 for ; Fri, 9 Oct 2015 13:12:03 +0200 (CEST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id BCA15C0C386C; Fri, 9 Oct 2015 11:12:02 +0000 (UTC) Received: from dhcp195.koti.laiskiainen.org (vpn1-6-191.ams2.redhat.com [10.36.6.191]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t99BC1RS018194; Fri, 9 Oct 2015 07:12:01 -0400 To: "Montorsi, Francesco" , Thomas Monjalon References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902125650.GA10364@bricha3-MOBL3> <3003120.8bdQ5bCz5C@xps13> <56177A00.9060201@redhat.com> <69ead0cc07ec49f884b92de0756de3df@bilemail1.empirix.com> <786931fdd268483eb6623389603dfbb6@bilemail1.empirix.com> From: Panu Matilainen Message-ID: <5617A100.5040502@redhat.com> Date: Fri, 9 Oct 2015 14:12:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <786931fdd268483eb6623389603dfbb6@bilemail1.empirix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] rte_eal_init() alternative? 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: Fri, 09 Oct 2015 11:12:04 -0000 On 10/09/2015 01:13 PM, Montorsi, Francesco wrote: >>> It seems the patch missed the boat :) >> >> Correct, sorry. I'm attaching it now. > Ok, for some reason the email client is removing the attachment... I'm copying and pasting it: > (the points marked as TODO are functions that still contain rte_panic() calls...) I actually did receive the attachment from the previous mail, but inlined patches are far better for commenting purposes. > + */ > +struct internal_config; > +int rte_eal_init_raw(const char* logid, struct internal_config *cfg); Like the name indicates, struct internal_config is internal to librte_eal, you'd need to "export" the eal_internal_cfg.h header for this to be useful to users outside librte_eal itself. But I'd say there's a reason why its internal... > - if (rte_eal_pci_init() < 0) > - rte_panic("Cannot init PCI\n"); > + if (rte_eal_pci_init() < 0) { > + RTE_LOG (ERR, EAL, "Cannot init PCI\n"); > + return -1; > + } > > #ifdef RTE_LIBRTE_IVSHMEM > - if (rte_eal_ivshmem_init() < 0) > - rte_panic("Cannot init IVSHMEM\n"); > + if (rte_eal_ivshmem_init() < 0) { > + RTE_LOG (ERR, EAL, "Cannot init IVSHMEM\n"); > + return -1; > + } > #endif > > - if (rte_eal_memory_init() < 0) > - rte_panic("Cannot init memory\n"); > + if (rte_eal_memory_init() < 0) { > + RTE_LOG (ERR, EAL, "Cannot init memory\n"); > + return -1; > + } [...] Something like that, sure. The big question with this conversion is what to do with already allocated/initialized resources in case of failure, which I'd guess is the reason rte_panic() is there - to avoid having to deal with all that. Getting to a point where all or even most inialization can be undone in case of failure is likely going to be a long road, I think many subsystems dont even have a shutdown function. To beging with, EAL itself doesn't have one :) Anyway, one has to start someplace. But in order to make the cleanup eventually possible, I'd suggest using a common point of exit instead of a dozen returns, ie something in spirit of { [...] if (rte_eal_pci_init() < 0) { RTE_LOG (ERR, EAL, "Cannot init PCI\n"); goto err; } if (rte_eal_memory_init() < 0) RTE_LOG (ERR, EAL, "Cannot init memory\n"); goto err; } [...] return 0; err: /* TODO: undo all initialization work */ return -1; } - Panu -