Re: [PATCH 10/11] introduce container_of macro

From: Derrick Stolee <stolee@gmail.com>
Date: Aug 27, 2019, 14:49 UTC
Message-ID: <381dd52f-f7d4-3e6c-24b8-22c8a0710f25@gmail.com>
In-Reply-To: <20190826024332.3403-11-e@80x24.org>

On 8/25/2019 10:43 PM, Eric Wong wrote:

Show 12 quoted lines

> This macro is popular within the Linux kernel for supporting
> intrusive data structures such as linked lists, red-black trees,
> and chained hash tables while allowing the compiler to do
> type checking.
> 
> I intend to use this to remove the limitation of "hashmap_entry"
> being location-dependent and to allow more compile-time type
> checking.
> 
> This macro already exists in our source as "list_entry" in
> list.h and making "list_entry" an alias to "container_of"
> as the Linux kernel has done is a possibility.

[snip]

Show 11 quoted lines

> +/*
> + * container_of - Get the address of an object containing a field.
> + *
> + * @ptr: pointer to the field.
> + * @type: type of the object.
> + * @member: name of the field within the object.
> + */
> +#define container_of(ptr, type, member) \
> +	((type *) ((char *)(ptr) - offsetof(type, member)))
> +
>  #endif

I think it would be good to include at least one use of this macro in this patch. As it stands, I need to look at the next patch to make sense of what this is doing.

It took me a little while to parse what is happening here. 'ptr' is a pointer to the generic struct (in our case, 'struct hashmap_entry *'), while 'type' is the parent type, and 'member' is the name of the member in 'type' that is of type typeof(*ptr).

Perhaps this is easier to grok for others than it was for me.

-Stolee