RE: [RFC] An idea for general kernel post-processing automation in FreeBSD

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.architechture
Message-ID <[email protected]>
Hans Petter Selasky <hps_at_selasky.org> wrote on
Date: Sun, 21 May 2023 20:13:20 UTC :

> . . .
> I've put up a review for FreeBSD-14-main for discussion at:
> 
> https://reviews.freebsd.org/D40193
> 
> Depending patches are:
> 
> https://cgit.freebsd.org/src/commit/?id=805d759338a2be939fffc8bf3f25cfaab981a9be

That commit changes an example usage of the linuxkpi DEFINE_MUTEX
in dev/mlx4/mlx4_core/mlx4_main.c .

The RFC note does not seem to address a related Linux vs.
FreeBSD issue involved (uniqueness of global symbols vs. not
related and moving static's in a function to instead be
global).

The relationship with and handling of the linuxkpi may need to be
part of the "arch" discussion or the reviews.

For reference:

DEFINE_MUTEX is defined in:

# grep -r "define.*DEFINE_MUTEX" /usr/main-src/sys/ | more
/usr/main-src/sys/compat/linuxkpi/common/include/linux/mutex.h:#define  DEFINE_MUTEX(lock)

The commit (white space details may not be preserved):

diff --git a/sys/dev/mlx4/mlx4_core/mlx4_main.c b/sys/dev/mlx4/mlx4_core/mlx4_main.c
index ca63d1d12ba6..a37b900a2ed0 100644
--- a/sys/dev/mlx4/mlx4_core/mlx4_main.c
+++ b/sys/dev/mlx4/mlx4_core/mlx4_main.c
@@ -1164,6 +1164,8 @@ err_sup:
 	return err;
 }
 
+static DEFINE_MUTEX(set_port_type_mutex);
+
 static ssize_t set_port_type(struct device *dev,
 			     struct device_attribute *attr,
 			     const char *buf, size_t count)
@@ -1172,7 +1174,6 @@ static ssize_t set_port_type(struct device *dev,
 						   port_attr);
 	struct mlx4_dev *mdev = info->dev;
 	enum mlx4_port_type port_type;
-	static DEFINE_MUTEX(set_port_type_mutex);
 	int err;
 
 	mutex_lock(&set_port_type_mutex);

> https://reviews.freebsd.org/D40190
> https://reviews.freebsd.org/D40191
> https://reviews.freebsd.org/D40192

===
Mark Millard
marklmi at yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.