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 X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE2E6C63697 for ; Wed, 18 Nov 2020 13:47:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 793E72467D for ; Wed, 18 Nov 2020 13:47:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KK8hcSyH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726464AbgKRNrG (ORCPT ); Wed, 18 Nov 2020 08:47:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725747AbgKRNrG (ORCPT ); Wed, 18 Nov 2020 08:47:06 -0500 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13EEEC0613D4; Wed, 18 Nov 2020 05:47:06 -0800 (PST) Received: by mail-pl1-x644.google.com with SMTP id j5so1000835plk.7; Wed, 18 Nov 2020 05:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X5ywAJ6hWYCp4zIQL5SFOchJJGT8G6Lmy+RBQsqA3eM=; b=KK8hcSyHN1x9BMssreZhy3CV4f3N0K2duxHa7JJjaYsyDEAF34B/nnKLYKQqbr7lGE tkeQ+RK9KMuuMWKoL/8kknp3z61Zoa2QrxO+dhdjfXy/YG8+EbhtEXbe3+bTbQaFC6Js 8p/PHjCx2nSFto/dmiXlvUCzFdBHevcc9PAw3ahUZPPq+nlmMH+aSLyr5ZR/Vpws3g41 tvXgEK7leAXh88s1wrIH5rEwvi7+Bx2UXM27ULBkk/7QF1fSn1CbmmSPr1NrYCWLS/hJ AZjjh+8TTRn6tBfyD3nm/lgXr3Fr5Z53c8oE3yweB5FQFj2OSlOYzB0mo0c4r9ICMEHX ALwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X5ywAJ6hWYCp4zIQL5SFOchJJGT8G6Lmy+RBQsqA3eM=; b=Sk5ixQZEZAv++v5QyTRqIPOwZgrIU5vSYrpi9hA8sXoRlQlDP79BXlWRy/ztdB+urp msS7WMzjWbLAxLogBJnUpi3Xu6sD/xPOwuVI52Szi63QIZgEEU3qF6/Ai0bM+S8sO1Rv 5zJWgEBYmxI0WuPsYY87/iDWAcsJOhGPhzHJGAAE2Ui5iXLjrIFBFl3XUHSjEAqwjaMP MViPsURMWer6WIa601I3KnT6ZivvcrtuCSqGQmSmmfzArNG/UxTj3Q3MtrCLvQ23f1Yq Lijb8EpGGDs7vDq++Ent/vGePRvC4j7orFVynwSimjDEz5dYtdLNRxCKDmalspUpe9Zk MKqQ== X-Gm-Message-State: AOAM530H0bLM+ZR2cFVflsVW05NDRGBRA0CfsDBQr5ZDBuFlTAIUFcUU X+lppl0DZif1m8cq7CEmLVNZ3L+rFOs+l8dP5IQ= X-Google-Smtp-Source: ABdhPJxogQlvAx94fQeHfJV/ZRIN+bHPnokd5qtAAE39CaXWWnsSyC8aguiBZNVGXzoy6XMXjiko7djaaLkrnQI+2gg= X-Received: by 2002:a17:90a:4884:: with SMTP id b4mr97647pjh.198.1605707225568; Wed, 18 Nov 2020 05:47:05 -0800 (PST) MIME-Version: 1.0 References: <20201116135522.21791-1-ms@dev.tdt.de> <20201116135522.21791-6-ms@dev.tdt.de> In-Reply-To: From: Xie He Date: Wed, 18 Nov 2020 05:46:54 -0800 Message-ID: Subject: Re: [PATCH net-next v2 5/6] net/lapb: support netdev events To: Martin Schiller Cc: Andrew Hendry , "David S. Miller" , Jakub Kicinski , Linux X25 , Linux Kernel Network Developers , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 18, 2020 at 5:03 AM Xie He wrote: > > On Wed, Nov 18, 2020 at 12:49 AM Martin Schiller wrote: > > > > I also have a patch here that implements an "on demand" link feature, > > which we used for ISDN dialing connections. > > As ISDN is de facto dead, this is not relevant anymore. But if we want > > such kind of feature, I think we need to stay with the method to control > > L2 link state from L3. > > I see. Hmm... > > I guess for ISDN, the current code (before this patch series) is the > best. We only establish the connection when L3 has packets to send. > > Can we do this? We let L2 handle all device-up / device-down / > carrier-up / carrier-down events. And when L3 has some packets to send > but it still finds the L2 link is not up, it will then instruct L2 to > connect. > > This way we may be able to both keep the logic simple and still keep > L3 compatible with ISDN. Another solution might be letting ISDN automatically connect when it receives the first packet from L3. This way we can still free L3 from all handlings of L2 connections.