From mboxrd@z Thu Jan 1 00:00:00 1970 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 C3CDCC77B76 for ; Tue, 18 Apr 2023 11:58:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231634AbjDRL57 (ORCPT ); Tue, 18 Apr 2023 07:57:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231485AbjDRLz4 (ORCPT ); Tue, 18 Apr 2023 07:55:56 -0400 Received: from sonata.ens-lyon.org (domu-toccata.ens-lyon.fr [140.77.166.138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE4419EC9; Tue, 18 Apr 2023 04:54:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id C075C2014A; Tue, 18 Apr 2023 13:54:10 +0200 (CEST) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVlKHqG3c8RX; Tue, 18 Apr 2023 13:54:10 +0200 (CEST) Received: from begin.home (apoitiers-658-1-118-253.w92-162.abo.wanadoo.fr [92.162.65.253]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id 6C9052013E; Tue, 18 Apr 2023 13:54:10 +0200 (CEST) Received: from samy by begin.home with local (Exim 4.96) (envelope-from ) id 1pojuT-00Bypv-39; Tue, 18 Apr 2023 13:54:09 +0200 Date: Tue, 18 Apr 2023 13:54:09 +0200 From: Samuel Thibault To: Guillaume Nault Cc: James Chapman , tparkin@katalix.com, edumazet@google.com, davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, corbet@lwn.net, netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] PPPoL2TP: Add more code snippets Message-ID: <20230418115409.aqsqi6pa4s4nhwgs@begin> Mail-Followup-To: Samuel Thibault , Guillaume Nault , James Chapman , tparkin@katalix.com, edumazet@google.com, davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, corbet@lwn.net, netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230416220704.xqk4q6uwjbujnqpv@begin> <20230418085323.h6xij7w6d2o4kxxi@begin> <20230418091148.hh3b52zceacduex6@begin> <20230418103140.cps6csryl2xhrazz@begin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Guillaume Nault, le mar. 18 avril 2023 13:25:38 +0200, a ecrit: > As I said in my previous reply, a simple L2TP example that goes until PPP > channel and unit creation is fine. But any more advanced use of the PPP > API should be documented in the PPP documentation. When it's really advanced, yes. But here it's just about tunnel bridging, which is a very common L2TP thing to do. > I mean, these files document the API of their corresponding modules, > their scope should be limitted to that (the PPP and L2TP layers are > really different). I wouldn't call + ret = ioctl(ppp_chan_fd, PPPIOCBRIDGECHAN, &chindx2); + close(ppp_chan_fd); + if (ret < 0) + return -errno; documentation... > That shouldn't preclude anyone from describing how to combine L2TP, PPP > and others to cover more advanced use cases. It's just better done in a > different file. A more complete example, yes. I don't plan on taking time to do it. Samuel