Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp348056ybh; Mon, 20 Jul 2020 18:52:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkjjFtJhpGDyyOMfDNQqw0qLpJSch5FhV/kmW1eA6GAXps08Rhs9u/+5LHd0QGKtad7s8R X-Received: by 2002:a05:6402:174e:: with SMTP id v14mr24056243edx.153.1595296366199; Mon, 20 Jul 2020 18:52:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595296366; cv=none; d=google.com; s=arc-20160816; b=nvYVcw+ecEZeRA6U0ceBoMUYB2+krEHzN5l48frOqAsYMeEwnug8OegL4uioAaHzks unisJmuHfOzK4qCceMqBThNqDx48Jg4uAs2t4VqB7mXIq4dNybiXa6jqg+V8c2aKe84V uIFIbfK+9Yl4BFrRZCst+NdpCyrEqXfdG8Anw7Zy4y9wideViVQqMnnlBYy4d8EpKLRG PCo2wY/1VKZHnitz/zwvngbGl1Wyectd/2A9DcobHW8kqD6A78VoOcO/r3vFGJj1fhpt 7fhs6YG6OBzM1Fxp+SBnhS9KL6j00qAWOSXy51QZH8zXtmWZWIATm5qZOPzHnUWct0rA mYIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=THxruS9YqbdIiJtkdfwIMq+7/Nc2g3NoN5en/qd3vWs=; b=UEM3rO/MCUpiTzw9l36mdz84VxMUmLjjnpagTNharAgxjT8MSQuHOxyvCX5JOvfoeh SrzbP1m9covBBnN90CVwp2R9ILNDURPY/DbtmUtNvKi8MfLUvjOsnRbrjnDloElD0R+B s7q08nS5nFGv3GmK8QNb+yi8hZ0aqmSUrpMCHSj1h0/b/dixlqgrp1hv9GIHdRzo0F7P CgZhY6KuDnrHu25BPgFCeiy5G+ni6XILics9ij+Z8DvGmd+hoc+xH2xzNrgutJBDgXBu Tu0d1hOtE8qVlinjUarPCTBqrVbAHevz45IXM/sGkLconIZUeHGiwmOvPrRpWWQwwYDa 0CMg== 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 c12si13959463edx.210.2020.07.20.18.52.23; Mon, 20 Jul 2020 18:52:46 -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 S1726677AbgGUBvS (ORCPT + 99 others); Mon, 20 Jul 2020 21:51:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:48658 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726021AbgGUBvS (ORCPT ); Mon, 20 Jul 2020 21:51:18 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EF74D20658; Tue, 21 Jul 2020 01:51:16 +0000 (UTC) Date: Mon, 20 Jul 2020 21:51:15 -0400 From: Steven Rostedt To: "Ahmed S. Darwish" Cc: Peter Zijlstra , Ingo Molnar , Will Deacon , Thomas Gleixner , "Paul E. McKenney" , "Sebastian A. Siewior" , LKML , Jonathan Corbet , linux-doc@vger.kernel.org Subject: Re: [PATCH v4 01/24] Documentation: locking: Describe seqlock design and usage Message-ID: <20200720215115.4c5276db@oasis.local.home> In-Reply-To: <20200720214400.5ec6a028@oasis.local.home> References: <20200519214547.352050-1-a.darwish@linutronix.de> <20200720155530.1173732-1-a.darwish@linutronix.de> <20200720155530.1173732-2-a.darwish@linutronix.de> <20200720214400.5ec6a028@oasis.local.home> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 20 Jul 2020 21:44:00 -0400 Steven Rostedt wrote: > > - * This is not as cache friendly as brlock. Also, this may not work well > > - * for data that contains pointers, because any writer could > > - * invalidate a pointer that a reader was following. > > + * See Documentation/locking/seqlock.rst > > I absolutely hate it when I see this. > > I much rather have the documentation next to the code. Because > honestly, I trust that comments next to the code will get updated if > the code changes much more likely than comments buried in the > Documentation directory. > > It's also more likely that I wont even bother looking at the doc > (because I wont trust it to be up to date) and just read the code and > try to figure it out. Or look at how others have used it. Never mind, I see that kerneldoc is added in patch 5, which helps. -- Steve