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=-3.8 required=3.0 tests=BAYES_00, 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 8D978C433E6 for ; Fri, 15 Jan 2021 08:07:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4D768221F7 for ; Fri, 15 Jan 2021 08:07:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732112AbhAOIH0 (ORCPT ); Fri, 15 Jan 2021 03:07:26 -0500 Received: from mail-oi1-f179.google.com ([209.85.167.179]:46130 "EHLO mail-oi1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725797AbhAOIHZ (ORCPT ); Fri, 15 Jan 2021 03:07:25 -0500 Received: by mail-oi1-f179.google.com with SMTP id q205so8686432oig.13; Fri, 15 Jan 2021 00:07:10 -0800 (PST) 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=KHJ4LFBTeySXrAB0B3j8k7W0q4a43BLWpsk73jsTU8I=; b=NoLkyZsN+ZgPjDcb6PrXIWaPgVLiEBhFVaC15tvTWzZTUId5jh5K/2zcATLH8Dbged jJRqx2FNWthMvuf3+4DHWomQZJp6WEMEXaxq+Sg988OYZV+tDGMeA2IjcgvTgRIzlRgO 0v733gm7fvpLvEQbsyRl3nhjFq04gtt3iK89wbJB03+KcE8Fj84HZRjdrOn7Tpt2RXmu OeoD0Yidw6DVRPpNyPfvph1PwfPUNKQ/jeQwIxOXXXeca3w5RqhNKRr+Oj/Ah/hiPgQ/ Ridhjq0vALzeGpzpJLZRZ2P/7f4BzGAey7zbzepgoZEi+XKgzbm3GmFp0DECLawgBnJY p2Pg== X-Gm-Message-State: AOAM531HPJYd5jpuHhRtnXxQY+jzgj6JX1uWIC5QKGQWGDjISXe4WT0G 4WNMY9Q1e/3YC9I2a02aiqiqxR7Lj8IV0XZNtQU= X-Google-Smtp-Source: ABdhPJxGZI0PFSd8/9cz6QQtwsEnLh5GsODfVqU6ivhGty9KZLXuVxw9DoF5rLCTCgOv7jS7bGnrUuqWBkh8Mye41/s= X-Received: by 2002:aca:4b16:: with SMTP id y22mr4929340oia.148.1610698004707; Fri, 15 Jan 2021 00:06:44 -0800 (PST) MIME-Version: 1.0 References: <20200916205434.GA10389@duo.ucw.cz> <87czyf5jjp.fsf@vps.thesusis.net> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 15 Jan 2021 09:06:33 +0100 Message-ID: Subject: Re: fbcon: remove soft scrollback code (missing Doc. patch) To: Daniel Vetter Cc: Linus Torvalds , Phillip Susi , Pavel Machek , Randy Dunlap , LKML , "linux-doc@vger.kernel.org" , Greg Kroah-Hartman , dri-devel , Linux Fbdev development list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, On Thu, Jan 14, 2021 at 5:11 PM Daniel Vetter wrote: > On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven wrote: > > On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter wrote: > > > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds > > > wrote: > > > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi wrote: > > > > > > Could we pause this madness? Scrollback is still useful. I needed it > > > > > > today... it was too small, so command results I was looking for > > > > > > already scrolled away, but... life will be really painful with 0 > > > > > > scrollback. > > > > > > > > > > > You'll need it, too... as soon as you get oops and will want to see > > > > > > errors just prior to that oops. > > > > > > > > > > > If it means I get to maintain it... I'm not happy about it but that's > > > > > > better than no scrollback. > > > > > > > > > > Amen! What self respecting admin installs a gui on servers? What do we > > > > > have to do to get this back in? What was so buggy with this code that > > > > > it needed to be removed? Why was it such a burden to just leave it be? > > > > > > > > It really was buggy, with security implications. And we have no maintainers. > > > > > > > > So the scroll-back code can't come back until we have a maintainer and > > > > a cleaner and simpler implementation. > > > > > > > > And no, maintaining it really doesn't mean "just get it back to the > > > > old broken state". > > > > > > > > So far I haven't actually seen any patches, which means that it's not > > > > coming back. > > > > > > > > The good news? If you have an actual text VGA console, that should > > > > still work just fine. > > > > IIRC, all of this was written for systems lacking VGA text consoles > > in the first place... > > > > > Also on anything that is remotely modern (i.e. runs a drm kernel > > > modesetting driver undearneath the fbdev/fbcon stack) there's a pile > > > more issues on top of just the scrollback/fbcon code being a mess. > > > > Would it help to remove DRM_FBDEV_EMULATION (instead)? > > It's a problem with the hardware. "Write some registers and done" > isn't how display blocks work nowadays. So your proposal amounts to > "no fbdev/fbcon for anything modern-ish". With "modern-ish" actually meaning: "desktop/gaming/mobile-style 3D-accelerated wide-color display hardware". There's plenty of display hardware that doesn't fall into that class, and is served by fbdev (also out-of-tree due to the moratorium) because of that. > Also I said "a pile more", most of the issues in fbcon/fbdev code > apply for all drivers. > > > > Specifically the locking is somewhere between yolo and outright > > > deadlocks. This holds even more so if the use case here is "I want > > > scrollback for an oops". There's rough sketches for how it could be > > > solved, but it's all very tricky work. > > > > When an oops happens, all bets are off. At that point, all information > > you can extract from the system is valuable, and additional locking > > issues are moot. > > Except the first oops then scrolls aways because it's getting buried > under further fail. Your locking needs to be minimally good enough to > not make the situation worse. When an oops happens, all bets are off... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds 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=-3.8 required=3.0 tests=BAYES_00, 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 29918C433DB for ; Fri, 15 Jan 2021 08:06:48 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 899D1221E9 for ; Fri, 15 Jan 2021 08:06:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 899D1221E9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A22CB6E17E; Fri, 15 Jan 2021 08:06:46 +0000 (UTC) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by gabe.freedesktop.org (Postfix) with ESMTPS id 67FEB6E17E for ; Fri, 15 Jan 2021 08:06:45 +0000 (UTC) Received: by mail-oi1-f179.google.com with SMTP id n186so853363oia.5 for ; Fri, 15 Jan 2021 00:06:45 -0800 (PST) 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=KHJ4LFBTeySXrAB0B3j8k7W0q4a43BLWpsk73jsTU8I=; b=tRmKi/8MViAHv1WZ9nxZNB8BK1gwnd8Dg+Z7pspjMvKmrxvDIGE7HExe/y+ltngWa2 9NiENbFjOdqxfrL+9R+qxP1QkVi0vzZLxzCJjVfPUyV/eXdGCFqVs799/MgZWfZUl894 K/tvhe2wzWbazvXV3SfThUDkRMW/DF44JXsw2ERq0bsy9hkRqwyomde06flkgNwCQ6kh 5xGjalDDBWphPSXtnPdr1lyEQEt9jHeCpO9QBibYHUj8vvcrlkxifhBiP9t5NS51AfuI 1m03MzPhbywWVUl/iqtHASIqZVnsjdkOF2vZgKVjDlkPDO6sw1LLuvvBzteMGwm0aeug 7I3A== X-Gm-Message-State: AOAM530coSH3DyG6zanLNFeSE0e3BwUaD8I2/CVfR1LL/Mpj5U60QwOs rlmcGzMnGB3aHWeK+8VXh0muCfDuHSYQiw60J+s= X-Google-Smtp-Source: ABdhPJxGZI0PFSd8/9cz6QQtwsEnLh5GsODfVqU6ivhGty9KZLXuVxw9DoF5rLCTCgOv7jS7bGnrUuqWBkh8Mye41/s= X-Received: by 2002:aca:4b16:: with SMTP id y22mr4929340oia.148.1610698004707; Fri, 15 Jan 2021 00:06:44 -0800 (PST) MIME-Version: 1.0 References: <20200916205434.GA10389@duo.ucw.cz> <87czyf5jjp.fsf@vps.thesusis.net> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 15 Jan 2021 09:06:33 +0100 Message-ID: Subject: Re: fbcon: remove soft scrollback code (missing Doc. patch) To: Daniel Vetter X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux Fbdev development list , Phillip Susi , "linux-doc@vger.kernel.org" , Greg Kroah-Hartman , Randy Dunlap , LKML , dri-devel , Pavel Machek , Linus Torvalds Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Daniel, On Thu, Jan 14, 2021 at 5:11 PM Daniel Vetter wrote: > On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven wrote: > > On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter wrote: > > > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds > > > wrote: > > > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi wrote: > > > > > > Could we pause this madness? Scrollback is still useful. I needed it > > > > > > today... it was too small, so command results I was looking for > > > > > > already scrolled away, but... life will be really painful with 0 > > > > > > scrollback. > > > > > > > > > > > You'll need it, too... as soon as you get oops and will want to see > > > > > > errors just prior to that oops. > > > > > > > > > > > If it means I get to maintain it... I'm not happy about it but that's > > > > > > better than no scrollback. > > > > > > > > > > Amen! What self respecting admin installs a gui on servers? What do we > > > > > have to do to get this back in? What was so buggy with this code that > > > > > it needed to be removed? Why was it such a burden to just leave it be? > > > > > > > > It really was buggy, with security implications. And we have no maintainers. > > > > > > > > So the scroll-back code can't come back until we have a maintainer and > > > > a cleaner and simpler implementation. > > > > > > > > And no, maintaining it really doesn't mean "just get it back to the > > > > old broken state". > > > > > > > > So far I haven't actually seen any patches, which means that it's not > > > > coming back. > > > > > > > > The good news? If you have an actual text VGA console, that should > > > > still work just fine. > > > > IIRC, all of this was written for systems lacking VGA text consoles > > in the first place... > > > > > Also on anything that is remotely modern (i.e. runs a drm kernel > > > modesetting driver undearneath the fbdev/fbcon stack) there's a pile > > > more issues on top of just the scrollback/fbcon code being a mess. > > > > Would it help to remove DRM_FBDEV_EMULATION (instead)? > > It's a problem with the hardware. "Write some registers and done" > isn't how display blocks work nowadays. So your proposal amounts to > "no fbdev/fbcon for anything modern-ish". With "modern-ish" actually meaning: "desktop/gaming/mobile-style 3D-accelerated wide-color display hardware". There's plenty of display hardware that doesn't fall into that class, and is served by fbdev (also out-of-tree due to the moratorium) because of that. > Also I said "a pile more", most of the issues in fbcon/fbdev code > apply for all drivers. > > > > Specifically the locking is somewhere between yolo and outright > > > deadlocks. This holds even more so if the use case here is "I want > > > scrollback for an oops". There's rough sketches for how it could be > > > solved, but it's all very tricky work. > > > > When an oops happens, all bets are off. At that point, all information > > you can extract from the system is valuable, and additional locking > > issues are moot. > > Except the first oops then scrolls aways because it's getting buried > under further fail. Your locking needs to be minimally good enough to > not make the situation worse. When an oops happens, all bets are off... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel