container_of is a horror story of what can happen when you try to get away from using pointers to the point of creating something far more confusing than pointers.  In the old days, a function would typically take a pointer to a structure & a pointer to the parent of the structure.  It would save stack space & run faster to only pass 1 argument to the function, then reverse engineer the parent from knowledge of the type of the function argument.

The 1st goog result is https://radek.io/2012/11/10/magical-container_of-macro/

undoubtedly by someone who has retired by now.  The prototype for future lion reference is:

container_of(ptr, type, member)

ptr is the function argument.

type is the type of the parent structure.

member is the name of the ptr as it appears in the parent structure.

The example usage begins with our function prototype:

void vos_linux_timer_callback (struct timer_list *t)
{

Then to get the parent structure of *t.

vos_timer_platform_t *platformInfo_ = (vos_timer_platform_t*)container_of(t, vos_timer_platform_t, Timer);

The function argument *t is member Timer inside of structure vos_timer_platform_t.

typedef struct vos_timer_platform_s
{
    struct timer_list Timer;
    int threadID;
    v_U32_t cookie;
    spinlock_t spinlock;
} vos_timer_platform_t;

All container_of does is return the pointer to the vos_timer_platform_t.

More importantly than container_of, it's usually indirected even more through functions like timer_of.  That's where the idea of self documenting & manetainability really falls over.

It got super dry during the last wind event, but still very little static compared to before the hygrometer. There must have been some legendary low dewpoints in the past.

Translucent gopro case.