[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a7ixq24p.fsf@linutronix.de>
Date: Fri, 15 Feb 2019 02:19:50 +0100
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Daniel Wang <wonderfly@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Jiri Slaby <jslaby@...e.com>,
Peter Feiner <pfeiner@...gle.com>,
linux-serial@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [RFC PATCH v1 04/25] printk-rb: add writer interface
On 2019-02-15, John Ogness <john.ogness@...utronix.de> wrote:
> prb_commit() does not actually care what is in the handle. It is going
> to commit everything up to the reserve.
After thinking about what I wrote here, I realized that the struct
prb_handle has no purpose in this ringbuffer implementation. We really
could simplify the writer interface to:
char *prb_reserve(struct printk_ringbuffer *rb, unsigned int size);
void prb_commit(struct printk_ringbuffer *rb);
That probably feels really strange because the writer doesn't specify
_what_ to commit. But this ringbuffer implementation doesn't need to
know that.
The only reason I can think of for having a handle is if there should be
any statistics, debugging, or sanity checking added. (For example if a
writer tried to commit something it did not reserve.)
John Ogness
Powered by blists - more mailing lists