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 0CC5A42453; Sun, 22 Jan 2023 15:56:29 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AF74240223; Sun, 22 Jan 2023 15:56:28 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 9D03840150 for ; Sun, 22 Jan 2023 15:56:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674399386; 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=cydTzK/DQTJ8/K5wipRVB7UrY6YK/Ig5hMi4ILsiaaM=; b=UynJmNvYMYIK7O2hk66kFLasN7Tu3sE8CsQV/SUPmYrR5Wyd5XerLmaSmQXyTGiyGJFGZs bpFpkNy5+UrES3ZzwefIPLYy/cPFqJEdjdiqO1AZ7/wbsIHz35m4hbDdt3PJ+ubOnoVYpd UTurbfRL9n4Te+bYBTSzVufz8ZFF59U= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-589-IpSRB_WJNYCI29sN_ZWYpA-1; Sun, 22 Jan 2023 09:56:25 -0500 X-MC-Unique: IpSRB_WJNYCI29sN_ZWYpA-1 Received: by mail-pj1-f71.google.com with SMTP id lk5-20020a17090b33c500b00228cb369d7aso8011406pjb.5 for ; Sun, 22 Jan 2023 06:56:25 -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=cydTzK/DQTJ8/K5wipRVB7UrY6YK/Ig5hMi4ILsiaaM=; b=BITZOa3TjzHkCF9N58IRC/wIvlU5kwHEGv1hlqnVEOx1xqJFCr1RDf2+l8BRAj92Lc i/+a8u1+2iJ7h6Dymfz4wEH5CHeknevkEuiBjy1iReE2DGGkGO3tTTIue5w8Iv1i1eby fCXQtprRfW8aNaQeyzqh3Ss31IpqOgaNpK6y90aHdeYjHpUO1bFhTPKJ6b78tS/YI/OW YPmcUtVdD9NZiwsQmb0VoUd//r2q22b9cxrWk3mDaEdcAICLGDAy/S9LL8YR8ox8GRL/ L+JpDpz1LYLAfhe0lMjT21GZFh7ubuGt5qQBrxEqRJquWzk/2w2KyYbDMPcj6wTtTjL+ 4gXA== X-Gm-Message-State: AFqh2kodmgLU4kygPjarH6z2RxJqAvCCXrJTbKxik/G9mLnZihsgF3UX 3Ua2YLwhpfTb70GPoik66N5axDWhPAHyMot23KkpzX5Dy1yU3x3oti5ofbOGLTNgTveVGTSbfRu QZrqO6vozm0GgNB8DXGU= X-Received: by 2002:aa7:8283:0:b0:56b:b520:3751 with SMTP id s3-20020aa78283000000b0056bb5203751mr2295615pfm.29.1674399384366; Sun, 22 Jan 2023 06:56:24 -0800 (PST) X-Google-Smtp-Source: AMrXdXvAAm+VRqYH+MAJ8xsDgKjMxAgzLBDkYYc1cUYOzYHG/bymWWMEYcfTsumdHO50DNQ55aJbVnj2wDZ4bnQ0WMM= X-Received: by 2002:aa7:8283:0:b0:56b:b520:3751 with SMTP id s3-20020aa78283000000b0056bb5203751mr2295612pfm.29.1674399384038; Sun, 22 Jan 2023 06:56:24 -0800 (PST) MIME-Version: 1.0 References: <20220829151901.376754-1-bruce.richardson@intel.com> <20230120182154.481039-1-bruce.richardson@intel.com> In-Reply-To: <20230120182154.481039-1-bruce.richardson@intel.com> From: David Marchand Date: Sun, 22 Jan 2023 15:56:12 +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 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. -- David Marchand