From nobody Fri Nov 26 17:15:50 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F2C2E18BA5CD for ; Fri, 26 Nov 2021 17:15:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J11bs4lGzz4kwQ for ; Fri, 26 Nov 2021 17:15:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1637946950; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6GL/OexTTQv2YyxQTOh8WNwCeLWWjdATM0m9GBk1IVE=; b=GFt8yz6kHbxSW7EG+57wuWUs4qBfxvme866pr8isybZOMtmNTEKWDs/AcCNO0XKN2HwWeW 46qswHcvcIKgKrYyTrIHwfdgkukiENlNzV00+C898436Zq5qN2NJ7RNcfPXkbSQkrpXy7p M3vdqEaaslMcu4U02jfG5iacAcQQmWY= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 86832b6e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 26 Nov 2021 17:15:50 +0000 (UTC) Date: Fri, 26 Nov 2021 18:15:50 +0100 From: Emmanuel Vadot To: Eugene Grosbein Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20211126181550.ff4f633fd70fd8aa5a256f16@bidouilliste.com> In-Reply-To: <1b0eb704-9322-9b7a-363b-7ad5b55ecf7b@grosbein.net> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <5b9baa6a-66ee-549d-a3e9-f6ea4e6e5016@grosbein.net> <20211126171350.bf976c035095e1d8ac5e43fa@bidouilliste.com> <1b0eb704-9322-9b7a-363b-7ad5b55ecf7b@grosbein.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J11bs4lGzz4kwQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 26 Nov 2021 23:26:47 +0700 Eugene Grosbein wrote: > 26.11.2021 23:13, Emmanuel Vadot wrote: > > > Better as in it doesn't respect the specs ? > > People (except of programmers :-) do not work with specs, > they work with real pieces of metal. sc(4) works out of the box > and an upgrade does not ruin the system, so it is considered better. That's one way of seeing things. > I was forced to deal with production system broken with 11.1->11.2 upgrade (it used vt(4) by default) > and it was not fun. > > > You said yourself in this PR that we should blame the manufacturer. > > Now if you want to work on making hw.vga.acpi_ignore_no_vga better in > > loader based on the smbios info and some quirk table please go ahead. > > But don't say that sc(4) is better because it works on buggy hardware > > as it ignores some stuff. > > No, I will keep saying that compatibility with buggy hardware is better than lack of compatibility; > at least in case we already have the compatibility and going to lose it. And we have a workaround for this issue, I think it should be better so I understand your point here. BTW all those users with buggy system will never had this problem if they choose to use uefi but ... > >> I'd like more FreeBSD developers respect POLA these days > >> and take responds like "I've always used sc(4), it works for me don't touch it" seriously. > >> > >> Please, don't touch what works and works good. > >> > > > > Why POLA ? > > I'm asking for reasons to keep sc(4), how the hell is that POLA to ask > > some questions ? > > Removal of sc(4) will astonish part of our user base. We should avoid it. I'm not saying that we should remove sc(4) now obviously. I'm saying that remove it should be the plan (and I think have been for quite some time now) and I'd like to understand the last issues with vt(4) for this. -- Emmanuel Vadot