Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EC08C6FD1C for ; Mon, 13 Mar 2023 13:57:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230365AbjCMN47 (ORCPT ); Mon, 13 Mar 2023 09:56:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229910AbjCMN4s (ORCPT ); Mon, 13 Mar 2023 09:56:48 -0400 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 550BD664EB; Mon, 13 Mar 2023 06:56:42 -0700 (PDT) Received: by mail-qt1-f182.google.com with SMTP id c3so13139678qtc.8; Mon, 13 Mar 2023 06:56:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678715801; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3AmBuWVzCeWcPysh/zrfiCJW1ORbVCzeJReTTpgJTcI=; b=5koYIbNX02RCgAj53qg2QetZvWqhaY0qBTrfvc5sPRwYmd5VjlmXRo2dAI2MlPbZA/ 9mXQo/+hGqrTnjWWCrXyGAGjhMqscldplhd6f/KYm46YkUnSbYIIxpeTfbLJ7wHZk2Y5 pDfFihd/WxN997wrWA8g8gdBQahqNITovmg2Gxff7F+sKFYpxFcQWqihwbnInVQFHqHS eVEhc60BYqRh1LgLvFfORGmQvgH5m5rKVn43dz6loAuxyWXMFyrbkT0zyxPaS24swjom WzYy+ZpERi24PWStS72wSgWbyjl+ZDHYAdMCVZ5tULp04JuOGVwspXdJ33O79zLRkyoS uelA== X-Gm-Message-State: AO0yUKUQ8J7M1FcgZH4ZhCFA6omD8qIhtg20OvXMjJi7XLwvCXUnQHsJ dOr4wc9YeYYD7mPjRlBZTZXaFLennn71GHQU X-Google-Smtp-Source: AK7set8M7GFhu/FRzb/OXZlhngwMXusy+bFgyE0ELxozalvLkpJGdj3NJQRakdbvwSJsoQWJxWp+ZA== X-Received: by 2002:a05:622a:45:b0:3b9:ca95:da6e with SMTP id y5-20020a05622a004500b003b9ca95da6emr25579888qtw.44.1678715800955; Mon, 13 Mar 2023 06:56:40 -0700 (PDT) Received: from maniforge ([2620:10d:c091:400::5:b967]) by smtp.gmail.com with ESMTPSA id t6-20020a37ea06000000b007186c9e167esm294473qkj.52.2023.03.13.06.56.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 06:56:40 -0700 (PDT) Date: Mon, 13 Mar 2023 08:56:38 -0500 From: David Vernet To: Jonathan Corbet Cc: Bagas Sanjaya , Linux BPF , Linux Documentation , Linux Kernel Mailing List , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , "David S. Miller" , "Tobin C. Harding" Subject: Re: [PATCH bpf-next] bpf, doc: use internal linking for link to netdev FAQ Message-ID: <20230313135638.GD2392@maniforge> References: <20230313025119.17430-1-bagasdotme@gmail.com> <20230313030938.GA152792@maniforge> <4653cfd1-7209-6e49-4f01-fcc3f82f16ce@gmail.com> <20230313123602.GA2392@maniforge> <87wn3kvkkq.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wn3kvkkq.fsf@meer.lwn.net> User-Agent: Mutt/2.2.9 (2022-11-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 13, 2023 at 07:37:25AM -0600, Jonathan Corbet wrote: > David Vernet writes: > > > Sure, but there are practicalities to consider here. It takes O(minutes) > > to do a full docs build, as opposed to O(seconds). I've done reviews of > > docs patches where the engineer tried to build the docs tree, but > > thought it was hung and ended up cancelling it. Full docs builds also > > unfortunately spew quite a few warnings in other subtrees. You have to > > carefully wade through the warnings in those other subtrees to ensure > > you haven't added any new ones. > > > > It's hard enough to get people to write documentation. It's also hard > > enough to get them to test building their documentation before > > submitting it. I think there is a lot of value in being able to build > > the documentation for the subtree you're contributing to, and be able to > > have some expectation that it builds cleanly. Let's not make it more > > difficult for the people who are actually adding substantive > > documentation. > > I get your point, but that is essentially saying that there should be no > linkages between our documentation subtrees, which defeats much of the > purpose of using a system like Sphinx. I certainly agree that inter-subtree links are great to have, though in my opinion, other features such as linking kernel-doc comments, auto section labeling, etc make Sphinx very useful in their own right. But yes, having inter-subtree links is of course a useful feature as well. > In this specific case, though, there is a better solution. Text like: > > see the netdev FAQ (Documentation/process/maintainer-netdev.rst) > > will add links in the built docs, and also tells readers of the > plain-text files where they should be looking. Without adding warnings. Nice, seems like the best of both worlds. A syntax clarification question: are you saying that this would work? > see the `netdev-FAQ`_. > > > > .. _netdev-FAQ: Documentation/process/maintainer-netdev.rst Or is it required to have the full path inline in the text, as in your example: > see the netdev FAQ (Documentation/process/maintainer-netdev.rst) The benefit of the former is of course that you only have to specify the link in one place. > For the bigger problem, the right answer is to start using intersphinx. > I guess I need to get serious about playing with that. Based on a quick online search, that indeed sounds like the ideal solution. Thanks, David