Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp524285pxk; Wed, 2 Sep 2020 07:58:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqIEby2YkXju+O6zu5/lwc1yvLL62fQvA0EhFzbwQ2FastLh4vn3gh2Lr/T/Q5Fi5ou9MB X-Received: by 2002:aa7:d3da:: with SMTP id o26mr420833edr.169.1599058730035; Wed, 02 Sep 2020 07:58:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599058730; cv=none; d=google.com; s=arc-20160816; b=Th0nvendSpjkOuuYwsOvumMaybMexNwFh1kK3V1BwMn6LJRqEui5TMrJQt4QsF6F0J GyOTMr4jY/WIn1spuzGgQ4z9SCBXGQ8GeFK+XKILKuVtVuEUFCGbaXb8ckYl95GQ15V0 gwA5CoyAjYHLhXXm/uwvgVxrERKKDLor1ZMFJ6L7w6octP3+usUzBBnnPuHJxmZy776s Ivp8zPfwkUjDN7YV8B0x5ujlPzGvC7nibbxXyfe8FxeBdl1KnjTB0rcCKBUYLdXJ3WtT 2N3DL6l4KZXntoKKOXHCRdcG0Op7K/hcm6gG613tjageo8cZBRtmiH9qj+qR2ECH1Z6p pFkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=Y+/jML3LuA/1T6myPLpInHR+BhVlFHKZmnFiAz7pPAg=; b=TJjnbz2JOiNUmSyHYSVNpmgObVEMqVtq5D5b9ZlqeEb3T34YEG3yiFTXr+gdOrD3jY sFM+kOlNdaKkR5RKvb8sD35sqwv/CV5NvA1IxMgjF2d+Yvp77tSTSH6FG2bn+lBxc0UU fR8lurCehSek5PlEONlfuSljxnlTQSPnR07hqG+jRZGP/O5EdQSbsQ55wizQWFT8YNrb L9SXLxU/4ob8JG+aKgR3x+2paoh9v1+yqpopzdXrnE6NYntgTaVP/XylUBcvx7SxILSc gnzsqFyQcOvGU4LCeUUe4RlF32xbXlE+BeOm300bKkX7kenCC0IPh851+5CmOJ4QZsJZ 2xag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r12si2687742edq.93.2020.09.02.07.58.26; Wed, 02 Sep 2020 07:58:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728111AbgIBOuJ (ORCPT + 99 others); Wed, 2 Sep 2020 10:50:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:53498 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726871AbgIBOA6 (ORCPT ); Wed, 2 Sep 2020 10:00:58 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id BFBEEAEF3; Wed, 2 Sep 2020 14:00:56 +0000 (UTC) Date: Wed, 2 Sep 2020 16:00:55 +0200 (CEST) From: Miroslav Benes To: Joe Lawrence cc: Petr Mladek , Josh Poimboeuf , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, nstange@suse.de Subject: Re: refactoring livepatch documentation was Re: [PATCH 1/2] docs/livepatch: Add new compiler considerations doc In-Reply-To: <3842fe65-332e-9f90-fe75-7cd80b34b75e@redhat.com> Message-ID: References: <20200721161407.26806-1-joe.lawrence@redhat.com> <20200721161407.26806-2-joe.lawrence@redhat.com> <20200721230442.5v6ah7bpjx4puqva@treble> <20200722205139.hwbej2atk2ejq27n@treble> <20200806120336.GP24529@alley> <3842fe65-332e-9f90-fe75-7cd80b34b75e@redhat.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [side note: So not only that my INBOX is a mess after the summer. I also lost some emails apparently. I'm really sorry about that. ] CCing Nicolai too. > Hi Petr, Josh, > > The compiler optimization pitfall document can wait for refactored livepatch > documentation if that puts it into better context, particularly for newbies. > I don't mind either way. FWIW, I don't profess to be an authoritative source > its content -- we've dealt some of these issues in kpatch, so it was > interesting to see how they affect livepatches that don't rely on binary > comparison. > > > Toward the larger goal, I've changed the thread subject to talk about how we > may rearrange and supplement our current documentation. This is a first pass > at a possible refactoring... > > > 1. Provide a better index page to connect the other files/docs, like > https://www.kernel.org/doc/html/latest/core-api/index.html but obviously not > that extensive. Right now we have only a Table of Contents tree without any > commentary. > > 2. Rearrange and refactor sections: > > livepatch.rst > Keep just about everything > Add a history section to explain ksplice, kgraft, kpatch for the > uninitiated? > Add a section on source based vs. binary diff livepatch creation, > this may be worth its own top-level section > > Livepatch API > Basic API > Callbacks > Shadow variables > Cumulative patches > System state > > KLP Relocations > Right now this is a bit academic AFAIK kpatch is the only tool > currently making use of them. So maybe this document becomes a > more general purpose doc explaining how to reference unexported > symbols? (ie, how does kgraft currently do it, particularly > w/kallsyms going unexported?) Yes, we rely on kallsyms_lookup_name() pretty much right now and once we hit the problem with the next kernel version upgrade, we'll have to fix it. > Eventually this could contain klp-convert howto if it ever gets > merged. > > Compiler considerations > TBD > > I suppose this doesn't create a "Livepatching creation for dummies" guide, but > my feeling is that there are so many potential (hidden) pitfalls that such > guide would be dangerous. It does not create the guide, but it looks like a good basis. I agree with Josh here. It might be difficult at the beginning, but the outcome could be great even for a newbie and I think we should aim for that. > If someone were to ask me today how to start building a livepatch, I would > probably point them at the samples to demonstrate the basic concept and API, > but then implore them to read through the documentation to understand how > quickly complicated it can become. True. We discuss the need to properly document our internal process every once in a while and there is always something more important to deal with, but it is high time to finally start with that. Miroslav