On 2024-12-02 13:53, David Marchand wrote:
Convert spinlock (and as a consequence seqlock) to the clang
capability annotations.
Acked-by: Mattias Rönnnblom
Signed-off-by: David Marchand
---
drivers/bus/dpaa/base/qbman/qman.c | 4 ++--
drivers/net/fm10k/fm10k_ethdev.c | 4 ++-
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
On Wed, Dec 04, 2024 at 01:50:58PM -0800, Stephen Hemminger wrote:
> On Wed, 4 Dec 2024 12:09:49 -0800
> Andre Muezerie wrote:
>
> > Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
> > Therefore the errors below are seen with MSVC:
> >
> > ../lib/mldev/mldev_utils_scalar.
> On Wed, 4 Dec 2024 06:21:00 +
> Chaoyong He wrote:
>
> > > The definition of what a "dedicated queue" is a bit confusing.
> > > If it is only for LACP packets, it should never need to be very big.
> > > Only under a mis-configuration and DoS kind of flood should there
> > > ever be many pac
On Tue, Nov 26, 2024 at 04:52:27PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
> Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
> Therefore the errors below are seen with MSVC:
>
> ../lib/mldev/mldev_utils_scalar.c(465): error C2065:
> '__SIZEOF_LONG__': undeclared identifier
> ../lib/mldev/mldev_utils_scalar.c(478): error C2051:
> case expres
On Tue, Nov 26, 2024 at 04:52:26PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:28PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:24PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Wed, Oct 09, 2024 at 10:29:01PM +0200, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> > Sent: Thursday, 12 September 2024 06.52
> >
> > On Fri, Aug 09, 2024 at 10:14:38PM +0200, Mattias R??nnblom wrote:
> > > Extend bitset tests to cover the basic operatio
On Tue, Nov 26, 2024 at 04:52:23PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:22PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:21PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:20PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:19PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:18PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:17PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:15PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 19, 2024 at 09:32:07AM +0100, Morten Brørup wrote:
> > From: Andre Muezerie [mailto:andre...@linux.microsoft.com]
> > Sent: Tuesday, 19 November 2024 05.35
> >
> > From: Tyler Retzlaff
> >
> > MSVC struct packing is not compatible with GCC. Provide a macro that
> > can be used to pus
On Tue, Nov 26, 2024 at 04:52:12PM -0800, Andre Muezerie wrote:
> Ensure __rte_packed_begin and __rte_packed_end show up in pairs
> when checking patches.
>
> Signed-off-by: Andre Muezerie
> ---
Acked-by: Tyler Retzlaff
On Tue, Nov 26, 2024 at 04:52:16PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Replace macro
> __rte_packed with __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push.
>
On Tue, Nov 26, 2024 at 04:52:41PM -0800, Andre Muezerie wrote:
> Remove macro __rte_packed now that the code was made portable using
> __rte_packed_begin to push existing pack value
> and set packing to 1-byte and macro __rte_packed_end to restore
> the pack value prior to the push when MSVC is us
On Tue, Nov 26, 2024 at 04:52:13PM -0800, Andre Muezerie wrote:
> MSVC struct packing is not compatible with GCC. Add macro
> __rte_packed_begin which can be used to push existing pack value
> and set packing to 1-byte. Add macro __rte_packed_end to restore
> the pack value prior to the push.
>
>
Hi Dmitry,
Your observation is good!
But I have the /usr/lib/dpdk/pmds-24.0 in the LD_LIBRARY_PATH but since the
host does not have a match glibc, I have to run it with ld-linux-x86-64.so.2
specifying LD_LIBRARY_PATH with equivalent --library-path.
Here is the entire cmd I use to run testpmd:
On Tue, 3 Dec 2024 18:56:50 -0800
Andre Muezerie wrote:
> MSVC issues the warning below:
>
> ../lib/fib/trie.c(341): warning C4334: '<<':
> result of 32-bit shift implicitly converted to 64 bits
> (was 64-bit shift intended?)
>
> The fix is to cast the result explicitly to ptrdiff_t since it i
Add flow create/delete methods to TestPmdShell class
for initializing flow rules.
Signed-off-by: Dean Marx
---
dts/framework/remote_session/testpmd_shell.py | 59 ++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/dts/framework/remote_session/testpmd_shell.py
b/dt
Add dataclass for passing in flow rule creation arguments, as well as a
__str__ method for converting to a sendable testpmd command.
Signed-off-by: Dean Marx
---
dts/framework/remote_session/testpmd_shell.py | 44 ++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/
On Tue, 8 Oct 2024 08:59:58 -0700
Stephen Hemminger wrote:
> The xstats_get function in this driver did not act the same
> as other drivers when queried. The correct check is to look
> at the requested number of stats and compare it to the available
> stats and if the request is too small, retur
On Tue, 8 Oct 2024 08:59:56 -0700
Stephen Hemminger wrote:
> The xstats_get function in this driver did not act the same
> as other drivers when queried. The correct check is to look
> at the requested number of stats and compare it to the available
> stats and if the request is too small, retur
On Thu, 5 Dec 2024 00:50:24 +0300
Dmitry Kozlyuk wrote:
> Hi Igor,
>
> 2024-10-23 02:25 (UTC+0300), Igor Gutorov:
> > I've noticed an issue of `rte_memory_get_nchannel()` or
> > `rte_memory_get_nrank()` always returning zero regardless of the -n or
> > -r options set.
> >
> > I think this is du
On Wed, 4 Dec 2024 12:09:49 -0800
Andre Muezerie wrote:
> Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
> Therefore the errors below are seen with MSVC:
>
> ../lib/mldev/mldev_utils_scalar.c(465): error C2065:
> '__SIZEOF_LONG__': undeclared identifier
> ../lib/mlde
Hi Igor,
2024-10-23 02:25 (UTC+0300), Igor Gutorov:
> I've noticed an issue of `rte_memory_get_nchannel()` or
> `rte_memory_get_nrank()` always returning zero regardless of the -n or
> -r options set.
>
> I think this is due to `--in-memory` forcing `conf->no_shconf = 1`
> [1], which leads to `rt
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Hi Alipour,
It looks suspicious that on the host you don't see logs about loaded drivers,
like these ones that you see inside the VM:
> 2024-12-03 19:32:36.642042 EAL: open shared lib
> /usr/lib/dpdk/pmds-24.0/librte_net_fm10k.so.24.0
> 2024-12-03 19:32:36.642266 EAL: pmd.net.fm10k.init log le
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not const
On Wed, Dec 04, 2024 at 04:52:43PM +, Bruce Richardson wrote:
> On Wed, Dec 04, 2024 at 08:20:19AM -0800, Andre Muezerie wrote:
> > On Wed, Dec 04, 2024 at 08:56:35AM +0100, David Marchand wrote:
> > > Hello Andre,
> > >
> > > On Wed, Dec 4, 2024 at 3:20 AM Andre Muezerie
> > > wrote:
> > > >
Considering this problem further, I don't see a way to avoid the CLANG compiler
error with a function implementation. We would need a macro implementation
similar to CLANGS arm_neon.h. In addition, it may be necessary to provide
separate implementations for CLANG and non-CLANG compilers since
On Wed, Dec 04, 2024 at 08:20:19AM -0800, Andre Muezerie wrote:
> On Wed, Dec 04, 2024 at 08:56:35AM +0100, David Marchand wrote:
> > Hello Andre,
> >
> > On Wed, Dec 4, 2024 at 3:20 AM Andre Muezerie
> > wrote:
> > >
> > > MSVC issues the warning below:
> > >
> > > ../lib/lpm/rte_lpm.c(297): war
I will be taking on primary maintainer for this release.
Andrew has not been doing maintainer work on this branch so remove him.
Signed-off-by: Stephen Hemminger
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 60bdcce543..b56907
Devbind is one of the oldest tools in DPDK, and is written in a way that
uses a lot of string matching, no type safety, lots of global variables,
and has a few inconsistencies in the way it handles data (such as
differences between lspci calls and parsing in different circumstances).
This patch is
On Wed, Dec 04, 2024 at 08:56:35AM +0100, David Marchand wrote:
> Hello Andre,
>
> On Wed, Dec 4, 2024 at 3:20 AM Andre Muezerie
> wrote:
> >
> > MSVC issues the warning below:
> >
> > ../lib/lpm/rte_lpm.c(297): warning C4013
> > '__atomic_store' undefined; assuming extern returning int
> > .
On 12/2/2024 10:35 AM, Anatoly Burakov wrote:
Support for `--noiommu-mode` flag was added, but documentation for it was
not. Add documentation for the flag.
Signed-off-by: Anatoly Burakov
---
This update is also included in my devbind rewrite:
https://patches.dpdk.org/project/dpdk/list/?seri
Hi all,
Here is a list of patches targeted for stable release 21.11.9.
The planned date for the final release is 17th December 2024.
Please help with testing and validation of your use cases and report
any issues/results with reply-all to this mail. For the final release
the fixes and reported v
>
> clang14 does appear to support the vcopyq_laneq_u32() intrinsic, s0 we want
> to skip the conditional implementation.
>
> Two approaches I have tested to resolve the error are:
>
> 1) skip if building with clang:
>
>
> #if !defined(__clang__) && ((defined(RTE_ARCH_ARM) &&
> defined(R
On 12/2/2024 10:31 AM, Anatoly Burakov wrote:
Currently, when binding a device to VFIO, the UID/GID for the device will
always stay as system default (`root`). Yet, when running DPDK as non-root
user, one has to change the UID/GID of the device to match the user's
UID/GID to use the device.
This
On Wed, Dec 4, 2024 at 11:06 AM Thomas Monjalon wrote:
>
> 03/12/2024 08:54, David Marchand:
> > Start a new release cycle with empty release notes.
> > Bump version and ABI minor.
> > Bump libabigail from 2.4 to 2.6 and enable ABI checks.
> >
> > Signed-off-by: David Marchand
> Acked-by: Thomas
Signed-off-by: Anatoly Burakov
---
Notes:
v2:
- Added this patch to aid in review
- I believe it's better to squash it on apply
usertools/dpdk-devbind-new.py | 995 ---
usertools/dpdk-devbind.py | 1683 ++---
2 files changed, 913 inse
03/12/2024 08:54, David Marchand:
> Start a new release cycle with empty release notes.
> Bump version and ABI minor.
> Bump libabigail from 2.4 to 2.6 and enable ABI checks.
>
> Signed-off-by: David Marchand
Acked-by: Thomas Monjalon
Added a note about the new libabigail which will allow us
to
Hello Maxime Coquelin，
The scenario where I encountered coredump was ovs-dpdk，
similar to patch:
https://github.com/DPDK/dpdk/commit/52d874dc67055a943867456d3e5c730168bfba18.
Only one thread called rte_vhost_driver_unregister(), but at the same time,
two other threads called vhost_user_rea
Signed-off-by: Anatoly Burakov
---
Notes:
v2:
- Added this patch to aid in review
- I believe it's better to squash it on apply
usertools/dpdk-devbind-new.py | 995 ---
usertools/dpdk-devbind.py | 1683 ++---
2 files changed, 913 inse
From: Thomas Monjalon
Signed-off-by: Thomas Monjalon
---
VERSION | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/VERSION b/VERSION
index c09465eb07..0a492611a0 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-24.11.0-rc4
+24.11.0
--
2.43.0.windows.1
From: liaocaiqiang
---
lib/gso/gso_common.h | 39 +++
lib/gso/gso_tcp6.c| 62 +
lib/gso/gso_tcp6.h| 43
lib/gso/gso_tunnel_tcp6.c | 82 +++
lib/gso/gso_tunnel_tcp6.h | 44 +++
On 12/4/2024 10:45 AM, Anatoly Burakov wrote:
It has been suggested [1] that a major cleanup/rewrite of devbind would be
beneficial in terms of long term maintainability of the code. I was in a
coding mood over the weekend, and so I've went ahead and rewritten devbind.
Note that this is one gian
It has been suggested [1] that a major cleanup/rewrite of devbind would be
beneficial in terms of long term maintainability of the code. I was in a
coding mood over the weekend, and so I've went ahead and rewritten devbind.
Note that this is one giant patch, rather than a series of patches adjusti
It has been suggested [1] that a major cleanup/rewrite of devbind would be
beneficial in terms of long term maintainability of the code. I was in a
coding mood over the weekend, and so I've went ahead and rewritten devbind.
Note that this is one giant patch, rather than a series of patches adjusti
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, 4 December 2024 01.55
>
> On Wed, 4 Dec 2024 00:49:58 +0100
> Morten Brørup wrote:
>
> > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > Sent: Tuesday, 3 December 2024 22.39
> > >
> > > On Mon, 1
On 12/3/2024 11:16 PM, Stephen Hemminger wrote:
On Tue, 3 Dec 2024 11:25:00 +
Anatoly Burakov wrote:
Devbind is one of the oldest tools in DPDK, and is written in a way that
uses a lot of string matching, no type safety, lots of global variables,
and has a few inconsistencies in the way i
On 12/3/2024 6:07 PM, Stephen Hemminger wrote:
On Tue, 3 Dec 2024 11:25:00 +
Anatoly Burakov wrote:
+
+def check_installed(program: str, package: str) -> None:
+"""Check if a program is installed."""
+if subprocess.call(
+["which", program], stdout=subprocess.DEVNULL,
std
77 matches
Mail list logo
