Hi Steven,

> Date: 2026-10-22 16:53:36-0400
> From: Steven Rostedt <rostedt@goodmis.org>
>
[...]
> > 	struct my_seq_buf {
> > 		// .buffer points to the start of the buffer
> > 		char  *buffer;
> > 
> > 		/* .p points to the current position.  This is the last
> > 		 * '\0' that has been written to the buffer.  On
> > 		 * truncation, it is a NULL pointer.
> > 		 */
> > 		char  *p;
> > 
> > 		/* .end always holds ARRAY_END(buffer).  It is a pointer
> > 		 * one-past-the-last character in the buffer.
> > 		 */
> > 		char  *end;
> > 	};
> > 
[...]
> 
> I rather not increase its size. It is embedded in the trace_seq.

The size shouldn't change:

	alx@debian:~/tmp$ cat seq_buf_size_comparison.c 
	#include <stddef.h>
	#include <stdio.h>

	struct seq_buf {
		char    *buffer;
		size_t  size;
		size_t  len;
	};

	struct alx_seq_buf {
		char  *buffer;
		char  *p;
		char  *end;
	};

	int
	main(void)
	{
		printf("%zu\n", sizeof(struct seq_buf));
		printf("%zu\n", sizeof(struct alx_seq_buf));
	}
	alx@debian:~/tmp$ gcc -Wall -Wextra seq_buf_size_comparison.c 
	alx@debian:~/tmp$ ./a.out 
	24
	24

size_t and pointers should always have the same size, so this doesn't
change the size.

Am I missing something?


Cheers,
Alex

> Yes the seq_buf code can be complex, but it's in one location where it can
> be highly tested and verified. The point of seq_buf is to do the complexity
> so that other places in the kernel doesn't need to.
> 
> -- Steve
> 
> 

-- 
<https://www.alejandro-colomar.es>