Wireless Daemon for Linux
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz at gmail.com>
To: iwd at lists.01.org
Subject: Re: [PATCH v2 1/2] hwsim: allow concurrent radio creations
Date: Tue, 15 Feb 2022 11:53:02 -0600	[thread overview]
Message-ID: <f90c8063-e741-cf8d-b83f-bb50b0e9687e@gmail.com> (raw)
In-Reply-To: 20220215165242.1086346-1-prestwoj@gmail.com

[-- Attachment #1: Type: text/plain, Size: 3526 bytes --]

Hi James,

On 2/15/22 10:52, James Prestwood wrote:
> Currently CreateRadio only allows a single outstanding DBus message
> until the radio is fully created. 99% of the time this is just fine
> but in order to test dual phy cards there needs to be support for
> phy's appearing at the same time.
> 
> This required storing the pending DBus message inside the radio object
> rather than a single static variable.
> 
> To handle things a bit cleaner the radio info is now created when
> CreateRadio is called. The name is now a required arugment which allows

arugment->argument

> the NEW_RADIO event to lookup. This removes the duplicate code in the
> NEW_RADIO ack callback and leaves only error handling.
> ---
>   tools/hwsim.c | 147 +++++++++++++++++++++++++-------------------------
>   1 file changed, 73 insertions(+), 74 deletions(-)
> 

Yes, this looks much better now.

> v2:
>   * Removed creating the radio in multiple places. Instead only create
>     in the NEW_RADIO event.
> 

<snip>

> @@ -603,17 +611,18 @@ static void get_radio_callback(struct l_genl_msg *msg, void *user_data)
>   	struct l_genl_attr attr;
>   	uint16_t type, len;
>   	const void *data;
> -	const char *name = NULL;
> +	_auto_(l_free) char *name = NULL;
>   	const uint32_t *id = NULL;
>   	size_t name_len = 0;
>   	struct radio_info_rec *rec;
>   	uint8_t file_buffer[128];
>   	int bytes, consumed;
>   	unsigned int uintval;
> -	bool old;
> +	bool old = false;
>   	struct radio_info_rec prev_rec;
>   	bool name_change = false;
>   	const char *path;
> +	struct l_dbus_message *reply;
>   
>   	if (!l_genl_attr_init(&attr, msg))
>   		return;
> @@ -628,8 +637,7 @@ static void get_radio_callback(struct l_genl_msg *msg, void *user_data)
>   			break;
>   
>   		case HWSIM_ATTR_RADIO_NAME:
> -			name = data;
> -			name_len = len;
> +			name = l_strndup(data, len);

So why the strndup here?

>   			break;
>   		}
>   	}
> @@ -637,8 +645,13 @@ static void get_radio_callback(struct l_genl_msg *msg, void *user_data)
>   	if (!id || !name)
>   		return;
>   
> -	rec = l_queue_find(radio_info, radio_info_match_id, L_UINT_TO_PTR(*id));
> -	if (rec) {
> +	/*
> +	 * If the radio info exists without a pending dbus message this is a
> +	 * name change. Otherwise if the radio is not found something external
> +	 * created it, not hwsim.
> +	 */
> +	rec = l_queue_find(radio_info, radio_info_match_name, name);

If this is a name change, then how would this work?  I think you do need to 
match by id or by name.  This may be easier done with l_queue_get_entries style 
for loop.

For a radio that is 'in flight', we may want to set the id to something 
non-sensical like -1.

> +	if (rec && !rec->pending) {
>   		old = true;
>   		memcpy(&prev_rec, rec, sizeof(prev_rec));
>   
> @@ -647,13 +660,9 @@ static void get_radio_callback(struct l_genl_msg *msg, void *user_data)
>   			name_change = true;
>   
>   		l_free(rec->name);
> -	} else {
> -		old = false;
> -		rec = l_new(struct radio_info_rec, 1);
> -		rec->id = *id;
> -	}
> -
> -	rec->name = l_strndup(name, name_len);
> +		rec->name = l_strndup(name, name_len);

so either l_strndup _only_ here or l_stealptr if you already did that above. 
Assuming name isn't being used below.

> +	} else if (!rec)
> +		return;

This part seems suspicious.  What if the radio is being created outside hwsim?

>   
>   	l_genl_attr_init(&attr, msg);
>   

Regards,
-Denis

             reply	other threads:[~2022-02-15 17:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 17:53 Denis Kenzior [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-02-15 19:40 [PATCH v2 1/2] hwsim: allow concurrent radio creations Denis Kenzior
2022-02-15 19:16 James Prestwood
2022-02-15 16:52 James Prestwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f90c8063-e741-cf8d-b83f-bb50b0e9687e@gmail.com \
    --to=iwd@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox