Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp562525ybl; Wed, 28 Aug 2019 02:00:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqwJeeMJ7G50QLct+PAXilBC3qpoUqe9YRuXF1DxonJK7JZriSeFmQ4ABHVAR++kMhsxd+D4 X-Received: by 2002:a17:90a:db0d:: with SMTP id g13mr3180476pjv.51.1566982800204; Wed, 28 Aug 2019 02:00:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566982800; cv=none; d=google.com; s=arc-20160816; b=lAhnFLD7wHCap9poGk19Olq+aE9sZmdEuFNQezVo+NjJwJKoQFE2OUe6vTfoJi6Fzj 6Hxm5TPBBI+ljjC3x1xJf1WvFJvSH/IU2u6Bkjf0kSTGzk2eK+HMop/SAR/O6ITjkfMx Z5Sbbi1aRb04MsAuz9e2pp+84Djn140nykcrGdtnznHZGnnXg7QRii0l7YnQesNsGJ7D NctJ1Aj4+SaynbDS7pchaU3q5U/Dv+daL+8N387zqNrt5xD5kpSLv6mpSC/qD2jv1vdP ahe4dcVWSyORXTppgD0ESXsQv0Fo0SSyak8IUDZ0Rwh858Q1AuOWtRS7ORBzrsImjCh6 OqOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=TAZ15fLPofkWlTp/m0lpRdCU/ruUTAfLX0Zk3P9G+Ko=; b=isLr+zvn8e9klNjNi5uz8W2s3Dw81eBOu9f0Q/rJKsteJ+BM4ewxk3vnt9FKIqsH18 LJKJtsYnkZ9gqbKEklD+kh6nc0f0WjyQU0hmsIXVnBEY1zpF1E611HDH0fs9gYIijeGn TWt40O+u4tFQX41+9K3b3q2t8RSH+HFBnvcZLPjj3mH9bUK9+LDZdKVt6Hcu7KvyWKJe Zv7QhPmjRGOnc5S2zqkBpXsvg7cPDslXnA1i2/4eyQiTaGr8cTJCeAdUkc8XVFTUWRlL nQlZLEARhUUmQjN1PC8AqXNwqR/vR9Ch6XFRcBnb9k3hPxEt1sbDwoAPiR2iDX8p+ZmX 7Ggw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c9si1371017plo.192.2019.08.28.01.59.45; Wed, 28 Aug 2019 02:00:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726462AbfH1I6s (ORCPT + 99 others); Wed, 28 Aug 2019 04:58:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:33498 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726272AbfH1I6s (ORCPT ); Wed, 28 Aug 2019 04:58:48 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4EC19ADDA; Wed, 28 Aug 2019 08:58:46 +0000 (UTC) Date: Wed, 28 Aug 2019 10:58:45 +0200 From: Petr Mladek To: John Ogness Cc: Andrea Parri , Andrea Parri , Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Brendan Higgins , Peter Zijlstra , Thomas Gleixner , Linus Torvalds , Greg Kroah-Hartman , linux-kernel@vger.kernel.org Subject: Re: numlist API Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation Message-ID: <20190828085845.5k7ewfshbfed7txh@pathway.suse.cz> References: <20190807222634.1723-1-john.ogness@linutronix.de> <20190807222634.1723-2-john.ogness@linutronix.de> <20190823171802.eo2chwyktibeub7a@pathway.suse.cz> <20190823171802.eo2chwyktibeub7a@pathway.suse.cz> <87sgpnmqdo.fsf@linutronix.de> <20190827130349.6mrnhdlqyqokgsfk@pathway.suse.cz> <20190827130349.6mrnhdlqyqokgsfk@pathway.suse.cz> <87o909lq3g.fsf@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o909lq3g.fsf@linutronix.de> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 to review > > when the ID handling is "hardcoded" (helper functions). It could be > > made abstract anytime later when there is another user. > > > > 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. > > FWIW, I did _not_ create the numlist and dataring structures in order to > support some theoretical future user. PeterZ helped[0] me realize that > RFCv2 was actually using multiple internal data structures. Each of > these internal data structures has their own set of memory barriers and > semantics. By explicitly refactoring them behind strong APIs, the memory > barriers could be clearly visible and the semantics clearly defined. > > For me this was a great help in _simplifying_ the design. For me it also > greatly simplified debugging, testing, and verifying because I could > write tests for numlist and datalist that explicitly targeted those data > structures. Once I believed they were bullet-proof, I could move on to > higher-level tests of the printk_ringbuffer. And once I believed the > printk_ringbuffer was bullet-proof, I could move on to the higher-level > printk tests. When a problem was found, I could effectively isolate > which component failed their job. > > I understand that we disagree about the abstractions being a > simplification. This is a misunderstanding. I probably was not clear enough. It makes perfect sense to have separate APIs for numlist and dataring. I agree that they allow to split the problem into smaller pieces. 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. In particular, the numlist should allow only linking of reusable structures stored in an array. I explained in the previous mail that other use cases are questionable. If anyone really finds another usecase, the API might be made more generic. But we should start with something simple. > And I'm not sure how to proceed in this regard. (Maybe > once we get everything bullet-proof, we can put everything back together > into a monolith like RFCv2.) I would actually go the other way. It would be nice to add numlist and dataring API in separate patches. > Either way, please understand that the > abstractions were done for the benefit of printk_ringbuffer, not for any > theoretical future user. I understand. I hope that it is more clear now. Best Regards, Petr