From nobody Sat Sep 09 14:25:39 2023 X-Original-To: dev-commits-src-main@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 4RjZyh1cQwz4swwp; Sat, 9 Sep 2023 14:25:48 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RjZyh19Y5z3RpW; Sat, 9 Sep 2023 14:25:48 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1694269548; 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: in-reply-to:in-reply-to:references:references; bh=8nOX1HnKmktAJPhYdXT4bn7yKMgHoWWLMivI7OApijY=; b=Muti3JyfUVTNxNg2K66GebPn5FUA/NY/bUP5d0AVoY/bhlx/QtcubEFJSK+Yc5Qa9AxjAP GZA4KnnpuX8P9V/9YKY+h54tXrzk4fHnyNVQl9F2IuRTL7n30LObubL/oKGY5bjrfpAuFh 1GD8/jDmAOV+TDpAj1KRBYGQBN+49Rq56wS0EBG1oijsaAQEOttBTewIojyq3qd8IJ/ZSv 1eun8/xnVEfrZ6diSqCnfP0FMRuc9NS7Efcih+nOg6pITLnS5pDTVJdeLX7GHi/W+pC3zx ni3hm9V1Zf4dGsIFA8mUlkhmaoMMCmrnff7swiynFeSaoceCku7GKTB4pvC3PA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1694269548; a=rsa-sha256; cv=none; b=ru0mhRm3YEi/5ZFRmYFamxRwcwMkCOMFkLYd6VXv2st1tjT4h7vOK3ixgCqYWq1IsrgfTA BhoMw0lNxD9nTDmzKf4LKp9QQvY2YXnP6v/IjSVCuJAwzf3N1SkOncrSFxiikU28MIdvtf X5si17pj9Xvu2/gZr6XuocVy+W8XETnz+BgMCvazLH/G7GjizGA6KxIp3UoWfvaeLuxFui kLxzLBYJ89+lbeO08QBFg1qp2lkYh7v+6U867P1I2X1uhwTCBVH50ihjP2cQUQCH8NFVjF zCkBhpfpw/68us92eP471N/p2xtx0XWQeDmPYSYUdWDIpb1rLPLpzXutiULU2g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1694269548; 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: in-reply-to:in-reply-to:references:references; bh=8nOX1HnKmktAJPhYdXT4bn7yKMgHoWWLMivI7OApijY=; b=Q9NiS63gSrdVFdXaaYuXsygrhv13dQb6Zt1H1K3xHJliDpqQ8n7x5Q1TXHmotewPmaP3+E 9lew46N1M7z+wHnPvajvpJvRC03nKwq4pYEe6MdG+F2/9xt2UHzYnnDDQtNBL0NpNxJrxi eyERgOd+vDDhS5ZhOf/MUv9mfMqs+/mWA8+3MgN66Ij0kzPzTf6jMiDnRYGZqT/AAFdeXI nhlp/c4s/w71sGT0w6QqzywPtNKeQBQyuBuSUjfZ4ij6Hqryx1fIY4oBDMC20coRmPhh1U BvixEslTYlMuIq61tbIqsioivfXZl9dx7DkPVlK+SlzUhcYPjefd62+b/G+38Q== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RjZyf0pL8z17w6; Sat, 9 Sep 2023 14:25:45 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <095B47B6-A6EE-4AC7-A91B-3E12E72B0CE6@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_4172FBA6-63CD-4596-B5A3-95D6667CC331" List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: git: 1926d5cef6ea - main - init_main: Record completed SYSINITs Date: Sat, 9 Sep 2023 22:25:39 +0800 In-Reply-To: Cc: Colin Percival , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" To: Brooks Davis References: <202309061837.386Ib5AK086264@gitrepo.freebsd.org> <5BC96D9F-E4C4-4D34-B7B3-41576AD296DA@FreeBSD.org> X-Mailer: Apple Mail (2.3696.120.41.1.4) --Apple-Mail=_4172FBA6-63CD-4596-B5A3-95D6667CC331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 9, 2023, at 10:13 PM, Zhenlei Huang wrote: >=20 >=20 >=20 >> On Sep 8, 2023, at 2:19 AM, Brooks Davis > wrote: >>=20 >> On Wed, Sep 06, 2023 at 06:46:59PM -0700, Colin Percival wrote: >>> On 9/6/23 18:12, Zhenlei Huang wrote: >>>>> On Sep 7, 2023, at 2:37 AM, Colin Percival > wrote: >>>>> init_main: Record completed SYSINITs >>>>>=20 >>>>> When removing them from sysinit_list, append them to = sysinit_done_list; >>>>> print this list from 'show sysinit' along with the list of = future >>>>> sysinits. >>>>=20 >>>> So the `sysinit_done_list` is for DDB only. >>>=20 >>> Well... sort of. You can open up kgdb and run 'p = sysinit_done_list'. >>>=20 >>>>> static STAILQ_HEAD(sysinitlist, sysinit) sysinit_list; >>>>> +static struct sysinitlist sysinit_done_list =3D >>>>> + STAILQ_HEAD_INITIALIZER(sysinit_done_list); >>>>=20 >>>> Then it should be wrapped around with #ifdef DDB and #endif >>> I considered that, but since we're literally talking about 2 = pointers of >>> memory I figured it wasn't worth making it conditional. >>=20 >> IMO loss of the run order in a dump was a (minor) regression so this >> should be unconditionally available. >=20 > No, we do NOT loss the run order. >=20 > Given a kernel dump, we known its git commit hash, then the order of = all sysinit is determined, unless > we have non-stable sort of sysinits. >=20 > That is somewhat not as flexible as previous sysinit array, or current = `sysinit_done_list`. >=20 > So IMO `sysinit_done_list` is still useful only for debugging, either = DDB or kgdb. Think about it twice. End user may have custom kernel config. It can be = much useful when this system=20 has buggy sysinit order (not caught during dev / test), then a = `sysinit_done_list` can ease the debugging greatly.=20 >=20 >>=20 >> -- Brooks >=20 > Best regards, > Zhenlei --Apple-Mail=_4172FBA6-63CD-4596-B5A3-95D6667CC331 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Sep 9, 2023, at 10:13 PM, Zhenlei Huang <zlei@FreeBSD.org> = wrote:



On Sep 8, 2023, at 2:19 AM, = Brooks Davis <brooks@freebsd.org> wrote:

On Wed, Sep 06, 2023 at = 06:46:59PM -0700, Colin Percival wrote:
On 9/6/23 18:12, Zhenlei Huang wrote:
On Sep 7, = 2023, at 2:37 AM, Colin Percival <cperciva@FreeBSD.org> wrote:
   init_main: Record completed SYSINITs

   When removing them from = sysinit_list, append them to sysinit_done_list;
   print this list from 'show sysinit' along = with the list of future
   sysinits.

So the `sysinit_done_list` is for = DDB only.

Well... sort of. =  You can open up kgdb and run 'p sysinit_done_list'.

static STAILQ_HEAD(sysinitlist, sysinit) = sysinit_list;
+static struct sysinitlist sysinit_done_list = =3D
+ =    STAILQ_HEAD_INITIALIZER(sysinit_done_list);

Then it should be wrapped around = with #ifdef DDB and #endif
I considered that, = but since we're literally talking about 2 pointers of
memory= I figured it wasn't worth making it conditional.

IMO = loss of the run order in a dump was a (minor) regression so = this
should = be unconditionally available.

No, we do NOT loss the run = order.

Given a = kernel dump, we known its git commit hash, then the order of all sysinit = is determined, unless
we have non-stable sort = of sysinits.

That is somewhat not as flexible as previous sysinit array, or = current `sysinit_done_list`.

So IMO `sysinit_done_list` is still useful only for debugging, either DDB = or kgdb.

Think about it twice. End = user may have custom kernel config. It can = be much useful when this system 
has buggy sysinit order = (not caught during dev / test), then a `sysinit_done_list` can ease the = debugging
greatly. 



-- = Brooks

Best regards,
Zhenlei



= --Apple-Mail=_4172FBA6-63CD-4596-B5A3-95D6667CC331--