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 AD25543034; Fri, 11 Aug 2023 14:46:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 70EB140F16; Fri, 11 Aug 2023 14:46:33 +0200 (CEST) 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 453A840E03 for ; Fri, 11 Aug 2023 14:46:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691757990; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xxDYBSqUSLKEzAYzHIg3XCRhlV9xzlYBXqNpB/YK36o=; b=IziYDUbMswANyXbxrACz2aewL2hEC6qEv/NBFHJbkE7QcI45jH8Wuzt32Nl+GJ78HEAEdM mWfolUhorL2DkrLgV8fT1Q2PbzOmmyGltYTpKY8bNsJbbVIfv0idMJiOVC1do3eSfdg9Zj TG+iRIudBFyX23Oj1/g7y3nCX4wWTXQ= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-674-1qym2dSxMNaBVk4MxHzdvA-1; Fri, 11 Aug 2023 08:46:27 -0400 X-MC-Unique: 1qym2dSxMNaBVk4MxHzdvA-1 Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-4fe0fe8dfe0so1801003e87.0 for ; Fri, 11 Aug 2023 05:46:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691757986; x=1692362786; h=content-transfer-encoding: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=xxDYBSqUSLKEzAYzHIg3XCRhlV9xzlYBXqNpB/YK36o=; b=OIfF4uXaMLHGUaikhGVP/tsFPBcQlBcBSh6WW+ktTfUIsyBCQhcVEL1YyyyK7qgrZ8 /hFZaiHtT8uUjIjw0CLpAHRAlQ6ebjH0olcdRA5CCSd8PU6GN8c5ZK9wkcbYOOdtU6kQ sVf8NNjlZ6R9TJKBOz/akfwp6AuEuxfLjBOjgCOnmN8FwAR4jVU4CTGkZYXF2WKK6uO7 E0Xct+wxSF5WFoos2zj+5D27TuuPrwcGL8egNMFNSTxw13sZv6g5fawykzutd0obENVO kzTNHkSWZ0omSdyJwjm6d3CIh2HN8DO8rcJxHlXj9gJpVVCymHQ8ptwJCbg5HbPnANl5 OteQ== X-Gm-Message-State: AOJu0YzfH5QPOv7V+qPeHI22UJhH4J15XB6w1So4QaQ0WrvLav57212o yQ16hllsKw/MLwnBIhulDhfTrJzUnbhcF26tjJbcsAgYlINI7GH/1dqSRd/Fwd+WXqDCSdnqC/n dy7lMSEGgHWYKdzZ71e0= X-Received: by 2002:a05:6512:234b:b0:4fe:1438:1236 with SMTP id p11-20020a056512234b00b004fe14381236mr1798372lfu.13.1691757986017; Fri, 11 Aug 2023 05:46:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFcGs90yF6TCxqlGYJzK3jkk4oreCbRpTTtSWOIxkRk8Krhh2BAHOUZEABPgoil+RFAw4umcetzjYrQAgKSt/o= X-Received: by 2002:a05:6512:234b:b0:4fe:1438:1236 with SMTP id p11-20020a056512234b00b004fe14381236mr1798353lfu.13.1691757985624; Fri, 11 Aug 2023 05:46:25 -0700 (PDT) MIME-Version: 1.0 References: <20220829151901.376754-1-bruce.richardson@intel.com> <20230809133553.1396119-1-bruce.richardson@intel.com> In-Reply-To: <20230809133553.1396119-1-bruce.richardson@intel.com> From: David Marchand Date: Fri, 11 Aug 2023 14:46:13 +0200 Message-ID: Subject: Re: [PATCH v8 0/3] Split logging functionality out of EAL To: Bruce Richardson Cc: dev@dpdk.org, Thomas Monjalon , =?UTF-8?Q?Morten_Br=C3=B8rup?= X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, Aug 9, 2023 at 3:36=E2=80=AFPM 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. Series applied, thanks Bruce for this first step. As mentionned during the maintainers weekly call yesterday, this is only a first "easy" step but, thinking of next steps, more splitting may not be that easy. At least, on the libabigail topic, as we need the ABI check to handle libraries splits, a new feature has been cooked in (not yet released) 2.4 libabigail. https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dcommitdiff;h=3D0b338dfaf= 690993e123b6433201b3a8b8204d662 Hopefully, we will have a libabigail release available by the time we start the v24.03 release (and re-enable ABI checks). --=20 David Marchand