Re: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

2019-09-03 Thread Sergey Senozhatsky
On (08/27/19 15:03), Petr Mladek wrote: [..] > > IMHO the API is sane. The only bizarre rule is that the numlist must > > always have at least 1 node. But since the readers are non-consuming, > > there is no real tragedy here. > > > > My goal is not to create some fabulous abstract data structure

Re: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

2019-08-29 Thread Petr Mladek
On Wed 2019-08-28 16:03:38, John Ogness wrote: > On 2019-08-28, Petr Mladek wrote: > > I only think that, especially, numlist API is too generic in v4. > > It is not selfcontained. The consistency depends on external barriers. > > > > I believe that it might become fully self-contained and

Re: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

2019-08-28 Thread John Ogness
On 2019-08-28, Petr Mladek wrote: > I only think that, especially, numlist API is too generic in v4. > It is not selfcontained. The consistency depends on external barriers. > > I believe that it might become fully self-contained and consistent > if we reduce possibilities of the generic usage.

Re: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

2019-08-28 Thread Petr Mladek
On Wed 2019-08-28 09:13:39, John Ogness wrote: > On 2019-08-27, Petr Mladek wrote: > > The API is complicated because of the callbacks. It depends on a logic > > that is implemented externally. It makes it abstract to some extent. > > > > My view is that the API would be much cleaner and easier

Re: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

2019-08-28 Thread John Ogness
On 2019-08-27, Petr Mladek wrote: > The API is complicated because of the callbacks. It depends on a logic > that is implemented externally. It makes it abstract to some extent. > > My view is that the API would be much cleaner and easier to review > when the ID handling is "hardcoded" (helper

Re: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

2019-08-27 Thread Petr Mladek
On Tue 2019-08-27 01:57:39, John Ogness wrote: > On 2019-08-23, Petr Mladek wrote: > >> --- /dev/null > >> +++ b/kernel/printk/numlist.c > >> @@ -0,0 +1,375 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> + > >> +#include > >> +#include "numlist.h" > > > > struct numlist is really special

Re: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

2019-08-26 Thread John Ogness
On 2019-08-23, Petr Mladek wrote: >> --- /dev/null >> +++ b/kernel/printk/numlist.c >> @@ -0,0 +1,375 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> + >> +#include >> +#include "numlist.h" > > struct numlist is really special variant of a list. Let me to > do a short summary: > >+ FIFO queue

numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation

2019-08-23 Thread Petr Mladek
On Thu 2019-08-08 00:32:26, John Ogness wrote: > --- /dev/null > +++ b/kernel/printk/numlist.c > @@ -0,0 +1,375 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +#include > +#include "numlist.h" struct numlist is really special variant of a list. Let me to do a short summary: + FIFO queue