From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8924B4246E; Mon, 23 Jan 2023 15:32:14 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7A0C040684; Mon, 23 Jan 2023 15:32:14 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 4CFD6400EF for ; Mon, 23 Jan 2023 15:32:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674484331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6bZHzZ//i5lgDVIBfmLXWsQdNLya4xZsThQPTI71R1M=; b=MJT+Eal4zR+jlzOnJ4AmSet31tYdVpqgY8frhvD22Uv1RMSao+pOBebcjVkoyYND3ca26R yC96D++yx0DGwZlM4ky0AlU7mSLoOZA9VE9fDeEmA/yHH9iIZdT9ed+wOrk5tXWkGHtQDv byfFkZuV0pAC55HJnikzrcKN8akGsYE= Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-382-IkHQOEXsP1ekvAQ2vOJUUw-1; Mon, 23 Jan 2023 09:32:10 -0500 X-MC-Unique: IkHQOEXsP1ekvAQ2vOJUUw-1 Received: by mail-pg1-f200.google.com with SMTP id e184-20020a6369c1000000b0049de6cfcc40so5486644pgc.19 for ; Mon, 23 Jan 2023 06:32:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6bZHzZ//i5lgDVIBfmLXWsQdNLya4xZsThQPTI71R1M=; b=hArqpddXCYcEt4ahb7Z5yLBHf/WQa7ky7SiO809gVk3Z8tV23ir102lF5q2CKHYiq7 KVYujJSYKuWsouJbt5+5w+uATkpPSj3XQYra8hGEyVwyr7XjKf9nK+2SLH4J0qkeYVry ELrh7xHchHim9Q2uxj5NytShEE1NwLcqQSSEe5gqI+Dwsj7CiIBb5KM7F2TVra75a5Vp 76OVasHGl6qm1vrBo7M0bKRSoVtpHF8gZbrGlexuMH7vQDmrKratUwmiCHyiCTBQBd0w DFPgpOT0Hw8AJm7a8YhVpbKUKzxiIY+9oo0x0leODy+6OsiDvECAYv5YJkAIwqgCw8sF +5RQ== X-Gm-Message-State: AFqh2krgq07Qcdcp3Nck/DQ3IqX0PA9IlH+IGe15llDAUAZ5rJ63y/Sj slsnGNX/i6lrp2RtSwZ+vgU0HjPIcF3YbsYeScDbs/3tUnl3PwDp1inL0ROfYzGnzpFtvCSJ9yi +oh6Ec3t337Vszx0cZsM= X-Received: by 2002:a17:90b:3711:b0:226:197:63fd with SMTP id mg17-20020a17090b371100b00226019763fdmr2502915pjb.55.1674484329636; Mon, 23 Jan 2023 06:32:09 -0800 (PST) X-Google-Smtp-Source: AMrXdXtUhCu9GLH6gQZJ/rhaSnwASIzwunYCedyec1a+cLa94+QQ5lNnm03fmZ7G4z/lUsT97sH+Gd1vGbqop0b+01c= X-Received: by 2002:a17:90b:3711:b0:226:197:63fd with SMTP id mg17-20020a17090b371100b00226019763fdmr2502911pjb.55.1674484329365; Mon, 23 Jan 2023 06:32:09 -0800 (PST) MIME-Version: 1.0 References: <20220829151901.376754-1-bruce.richardson@intel.com> <20230120182154.481039-1-bruce.richardson@intel.com> In-Reply-To: From: David Marchand Date: Mon, 23 Jan 2023 15:31:58 +0100 Message-ID: Subject: Re: [PATCH v4 0/3] Split logging functionality out of EAL To: Bruce Richardson Cc: dev@dpdk.org, Thomas Monjalon , Dodji Seketeli X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Jan 23, 2023 at 3:24 PM Bruce Richardson wrote: > > On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote: > > Hi Bruce, > > > > On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson > > wrote: > > > > > > There is a general desire to reduce the size and scope of EAL. To this > > > end, this patchset makes a (very) small step in that direction by taking > > > the logging functionality out of EAL and putting it into its own library > > > that can be built and maintained separately. > > > > > > As with the first RFC for this, the main obstacle is the "fnmatch" > > > function which is needed by both EAL and the new log function when > > > building on windows. While the function cannot stay in EAL - or we would > > > have a circular dependency, moving it to a new library or just putting > > > it in the log library have the disadvantages that it then "leaks" into > > > the public namespace without an rte_prefix, which could cause issues. > > > Since only a single function is involved, subsequent versions take a > > > different approach to v1, and just moves the offending function to be a > > > static function in a header file. This allows use by multiple libs > > > without conflicting names or making it public. > > > > > > The other complication, as explained in v1 RFC was that of multiple > > > implementations for different OS's. This is solved here in the same > > > way as v1, by including the OS in the name and having meson pick the > > > correct file for each build. Since only one file is involved, there > > > seemed little need for replicating EAL's separate subdirectories > > > per-OS. > > > > There is another complication. > > > > The ABI check is not handling properly the case where symbols are > > moved to the new log library (even though the dependency to librte_log > > is explicit in librte_eal elf). > > For now, I don't have a good way to handle this. > > > > A workaround to pass the check is to suppress those symbols wrt the eal dump: > > [suppress_function] > > symbol_name_regexp = rte_log > > [suppress_function] > > symbol_name = rte_openlog_stream > > [suppress_function] > > symbol_name = rte_vlog > > > > But this is not a good solution because we would be losing checks on > > them for the rest of the v23 ABI life. > > > Right, I got error messages from the CI job for this too, but I also have > no idea how to work around this. Perhaps we only get to move content > between libraries when we do an ABI bump? Seems a bit restrictive, though. Moving symbols as you did does not seem an ABI breakage. An application that links to eal would see the dt_needed entry for the new log library, load it accordingly and gets the right symbols. -- David Marchand