lkml.org 
[lkml]   [2019]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation
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 that
> > everyone should use. But I did try to minimize numlist (and dataring) to
> > only be concerned with clearly defined and minimal responsibilities
> > without imposing unnecessary restrictions on the user.
>
> 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 functions). It could be
> made abstract anytime later when there is another user.

Makes sense.

> There should always be a reason why to make a code more complicated
> than necessary. It seems that the only reason is some theoretical
> future user and its theoretical requirements.

Agreed.

> Symmetry is really important. It is often sign of a good design.
>
> Simple and straightforward code is another important thing at
> this stage. The code is complicated and we need to make sure
> that it works. Any optimizations and generalization might
> be done later when needed.

Agreed.

-ss

\
 
 \ /
  Last update: 2019-09-03 09:59    [W:0.136 / U:7.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site