From nobody Wed May 24 06:28:50 2023 X-Original-To: freebsd-arch@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 4QR1VH0HJyz4CHDQ for ; Wed, 24 May 2023 06:28:55 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.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 4QR1VG1z8Tz3rTS; Wed, 24 May 2023 06:28:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1684909731; 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=O7NXkGZfhgPfrs/9ObxfyKZNSN5ga+kVzgJLC4EXGEo=; b=cwbee0Opnvk2Wtl8OrXyIMhG/QogOz/3jghfhlWbwrR3cTBCLA72faRdWF/uMZDd/yZjBv o1jPXQBtSWGtfzdAXYdN+f1nyGFFci9Qhttax/TOGMJNPEwwTpscYAGPEEBikBS34yysxd jFzoxax/qkcVPz8SxW5i3/qaN/FT+rQ= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 1957b914 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 24 May 2023 06:28:51 +0000 (UTC) Date: Wed, 24 May 2023 08:28:50 +0200 From: Emmanuel Vadot To: Kyle Evans Cc: John Baldwin , Mark Johnston , Hans Petter Selasky , Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD Message-Id: <20230524082850.ffc8793b6bb1b47325ae0139@bidouilliste.com> In-Reply-To: References: <394775eb-1000-60d9-2ddd-5c2aca6c99ea@selasky.org> <08ba506f-66c5-35eb-e992-ecf9dfeccf93@selasky.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4QR1VG1z8Tz3rTS X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, 23 May 2023 18:53:47 -0500 Kyle Evans wrote: > On Tue, May 23, 2023 at 6:39?PM John Baldwin wrote: > > > > On 5/23/23 6:30 AM, Mark Johnston wrote: > > > On Tue, May 23, 2023 at 08:00:53AM +0200, Hans Petter Selasky wrote: > > >> Hi Warner, > > >> > > >> When you make systems and use them, you get bound by them. If a syst= em makes > > >> a certain solution advantageous, it gets chosen, independent if it i= s a good > > >> solution or not. > > >> > > >> The reason for our disagreement is simply this: > > >> > > >> You are thinking like a politican and want to be popular in the curr= ent > > >> system of FreeBSD. > > >> > > >> I'm thinking like a mathematican regardless of what makes me popular= in the > > >> current system of FreeBSD. > > >> > > >> > > >> Why not state that from the start? Implementing Quick Sort in qsort(= ) and > > >> using that everywhere is a political decision. > > >> > > >> This is not a technical fight, it is a political fight. > > > > > > I don't agree. From my point of view, Warner's position is the > > > pragmatic one. We have perhaps 2% Linux's number of active > > > developers[*], but we are relatively much larger in terms of > > > performance, code complexity, size, etc.. > > > > > > Layering and simplicity of design are some of the main tools we have = to > > > counteract this imbalance. It helps reduce the amount of time > > > developers spend on bugs that aren't directly related to what they are > > > doing. It helps us think about and predict the behaviour of the syst= em > > > using only intuition. This tradeoff can mean that we do not provide = the > > > best possible performance in all cases, but that's often a reasonable > > > tradeoff in this rather non-mathematical world where we do not have > > > infinite resources. > > > > > > The existing SYSINIT bubblesort is a good example of this tradeoff. = At > > > the time it was written, it made sense to choose a simple, "good enou= gh" > > > solution and move on. Even now, this simple solution just works and = is > > > perfectly acceptable on the vast majority of systems where FreeBSD is > > > deployed. > > > > > > I see this attitude reflected in Warner's and others' replies, and I > > > agree with it. I suspect that Warner, rather than wanting to be popu= lar > > > per se, is replying in his own self-interest, which is to spend zero > > > time debugging anything that might break if we start doing extra work= at > > > compile time to sort linker sets. > > > > > > It could be that some specific use-case will make your proposal more > > > attractive. I don't mean to suggest that the topic should be closed > > > forever. So far though, having read the thread and D40193, I'm not > > > really sold. > > > > > > [*] I'm sure this number can vary wildly depending on how you define = it; > > > my impression from reading Linux lists for a while is just that we ha= ve > > > way fewer people who understand core pieces of the system. > > > > +1. > > > > Also, the concern over the runtime for the potential worst-case for qso= rt > > seems _way_ overblown compared to the actual unsorted arrays one will g= et > > out of the linker. The only possible downside of qsort that matters in > > this case is the stack usage. > > >=20 > IMO sorting at runtime is a minor feature by itself, too. I mentioned > in one of the reviews somewhere, we have in the past have had bugs due > to poor specification of sysinit order within a subsystem -- I'm > recalling a specific one that wasn't even that long ago, maybe three > or four years, that manu@ had hit because he did or didn't include > some device in his config that ended up shifting link order of other > objects and reversing two sysinits into an order that wasn't actually > functional. Yes this problem was a pain to debug (I mean just to understand the actual problem), and iirc it was never solved, I only had the issue on one machine that I don't use anymore and the problem went away and re-apears from time to time when sysinits where added. > We can still add some bits to test that (preferably a > tunable to reverse order within a subsystem rather than having to > re-link the kernel) even with sorting at link-time, but it sure does > look a lot less fragile if we have to sort it anyways and we just > reverse one criteria. >=20 > Thanks, >=20 > Kyle Evans >=20 --=20 Emmanuel Vadot