Date: Thu, 29 Aug 2019 14:03:00 +0200 From: "Kristof Provost" <kp@FreeBSD.org> To: "Konstantin Belousov" <kostikbel@gmail.com> Cc: "Li-Wen Hsu" <lwhsu@freebsd.org>, "FreeBSD Hackers" <freebsd-hackers@freebsd.org>, fcp@freebsd.org Subject: Re: FCP 20190401-ci_policy: CI policy Message-ID: <412537DD-D98F-4B92-85F5-CB93CF33F281@FreeBSD.org> In-Reply-To: <20190829114057.GZ71821@kib.kiev.ua> References: <CAKBkRUwKKPKwRvUs00ja0%2BG9vCBB1pKhv6zBS-F-hb=pqMzSxQ@mail.gmail.com> <20190829114057.GZ71821@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Aug 2019, at 13:40, Konstantin Belousov wrote: > On Wed, Aug 28, 2019 at 12:29:58PM +0800, Li-Wen Hsu wrote: >> It seems I was doing wrong that just changed the content of this FCP >> to "feedback", but did not send to the right mailing lists. >> >> So I would like to make an announcement that the FCP >> 20190401-ci_policy "CI policy": >> >> https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md >> >> is officially in "feedback" state to hopefully receive more comments >> and suggestions, then we can move on for the next FCP state. > > What problem does the document tries to solve ? Or rather, do we > really > have the problem that it claims to solve ? > There are, somewhat regularly, commits which break functionality, or at the very least tests. The main objective of this policy proposal is to try to improve overall code quality by encouraging and empowering all committers to investigate and fix test failures. >> From my experience, normal peer pressure is enough to get things >> fixed > quickly when it is possible to fix them quickly. If there is something > more non-trivial, esp. in the tests and not the build, I am sure that > a rule allowing anybody to do blind revert is much more harmful than > having a test broken. > > More, I know that tests are of very low quality, which means that > brokeness of the tests is not an indicator of anything until root > cause > is identified. > I’m not sure I agree with the characterisation that the tests are of low quality. My own experience with the pf tests is that they test a large section of the network stack and firewall code. They’ve identified several very really issues (both pre- and post commit on the epoch-isatin of the network stack, for example, as well as a fairly important issue with IPv6 reassembly). It’s certainly true that the pf tests often reveal issues that are not in pf but in other code. I wouldn’t agree that this is a sign of low quality tests, but instead I consider it a sign that we don’t have enough tests for the network stack itself. > Can we rely on the common sense of developers until there is indeed > the > visible problem ? > I don’t want to suggest that people simply don’t care about test failures, because that’s clearly not true. On the other hand, I do think we can do better. There are at least two open problem in the network stack that I currently can’t get anyone to look at, and where I personally do not have sufficient context (or time) to fix them myself. (#239380, #238870). This proposal isn’t a silver bullet, I don’t think there is such a thing, but I do believe that elevating the visibility and importance of test failures can help us improve overall quality. Best regards, Kristof From owner-freebsd-hackers@freebsd.org Thu Aug 29 14:28:59 2019 Return-Path: <owner-freebsd-hackers@freebsd.org> Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 24FA4D72D6 for <freebsd-hackers@mailman.nyi.freebsd.org>; Thu, 29 Aug 2019 14:28:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46K4jk2kdSz3FFh for <freebsd-hackers@freebsd.org>; Thu, 29 Aug 2019 14:28:57 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1567088936; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=fGy0RQ0sszQAPF/fBmm+bK0M1FIhVvdk4bQ2EuadAnrcjgbMM2wqY7NyLLd8JwqWKed78Abhlf82P yKx1cczkW5LK2te3j52S1d7i4k11NbJFPFJqI6bD/gYLTFx/rINGszOE7zftCPlM5vHJca8x6ftHuo 1x4T4r7yS4lz/b5FN0TbzOiTse3DUvIe3xhuUacIcvlXdA0ASAeaFtS6jPrc6yKcmh0mcx7ENNfj48 0+Qz1jYAdWFwipRMkfc77rFBPLUNaqOuIgWXT9TvQXS6tXcJcZHArxejrcy1u8+Wd9TiPQHJN2+1CW 4DsJQ16nS80iJq2hTE0oBorIGtV0JLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=NhfUR3+uWOkNIDXozDawCm9N7M+9jCNMCkXCaafNDkM=; b=FYSG3gg6yRfuYiudVHzcBXt0wcoB7Iyex9gVSBiSZjox7pzQKE+b5NNyBIc5clcHgQREkJusMl9qC Y4hkr5vZA2zH1fYIhOkwTaDyNYCROp2i8bhkYbdBA/sx6ZFo2dPGtF1ePT7Bmncb73MZNbTO7mgxRY SFkUn/RdDS7clmg50XfcD1xiUfKItDZ+EWrzFpKBMhnpBirhLPOzVf3Oij0VLXx5ysXJ1zcCrE8IHu v891YwyKuTxP7kL9phYZlxGm/ia+4qAv7cIqOFLOyR41/bSRPVXSbCL4nxGFhHksHGNladc1AM0xdg t4ZocP4FRyG/cxx8AVGU3j3HC47RVIA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=NhfUR3+uWOkNIDXozDawCm9N7M+9jCNMCkXCaafNDkM=; b=D/H/xoOpauWee2r4LPj58oxtoPg7FF3Rc/qCHCftiQdAgXIHJTEkG2cGYLYe2jjGrZ0FAXxQYWEG/ /ZvZ0QTqRuPkDhPR7CKneUOSBGGTKcVWaf0pV/HvQ9XqLO3byQ5D/tlg8LJqGJIsaYdMWF9efeim19 i+nPDi1+SoZhrLtHIuWLghR2L2ZbNu/WpLnttE4pNDOVZ9EKqq7j3l0kab4WUhcX6B6IIcT1hVBuPC duf/E+e3qvHbXLbSG0j9WE8O5ITP6PGLYkFkv0stzJQBlbVW0wgP0lKM6lApXWMhfd5xitL3bZKh9y Fr4QLH+ODBKysg53uzTs7ZjpGcSUgzg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 5391e919-ca69-11e9-85ed-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 5391e919-ca69-11e9-85ed-13b9aae3a1d2; Thu, 29 Aug 2019 14:28:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7TESrlT017362; Thu, 29 Aug 2019 08:28:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <be1690d4f1d1a784030711169b6fd416b2dd5c5c.camel@freebsd.org> Subject: Re: ichsmb(4) and msleep() From: Ian Lepore <ian@freebsd.org> To: cem@freebsd.org, Yuri Pankov <yuripv@yuripv.net> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Date: Thu, 29 Aug 2019 08:28:53 -0600 In-Reply-To: <CAG6CVpW1kYqg7NgK5WfOFRBcsb0WbM1G8A5PPfeTDpsZ8Cxw3A@mail.gmail.com> References: <7dfebbd3-85d6-c7b7-b83b-fae8b644649e@yuripv.net> <478965aa-5256-e356-5339-de6fb82c3459@selasky.org> <63daa36a-5c22-6b08-3cd7-562fa961ab61@yuripv.net> <7f6de96d-8b56-e242-8950-04a20b197bce@selasky.org> <311a21e3-ed61-8679-b416-b2a4c255c6e7@yuripv.net> <1f91f7a6-050d-d690-d374-6b06950d2ce2@yuripv.net> <CANCZdfpevZ2PyLa9yai6cA5JYgNybgyHp0=1=er+euJGcu9hew@mail.gmail.com> <4201916c-0f7f-0bf6-2d17-e9f6a1879ba7@yuripv.net> <CAG6CVpW1kYqg7NgK5WfOFRBcsb0WbM1G8A5PPfeTDpsZ8Cxw3A@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46K4jk2kdSz3FFh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 29 Aug 2019 14:28:59 -0000 On Wed, 2019-08-28 at 20:27 -0700, Conrad Meyer wrote: > On Wed, Aug 28, 2019 at 6:35 AM Yuri Pankov <yuripv@yuripv.net> wrote: > > > > Warner Losh wrote: > > > What's the advantages of doing this instead of deferring attach until the > > > interrupts are running? > > > > None that I can think of, just going with what was suggested and seeing > > other drivers doing the same. Could you please name a driver that > > defers attach until !cold? > > I think pretty much all drivers attach when interrupts are enabled > (not the same as !cold)? At least x86 enables interrupts on BSP at > SI_SUB_INTR, and DRIVER_MODULE drivers *load* at SI_SUB_DRIVERS, and > the INTR one is ordered before the other. My skim read is that > drivers do not actually attach until SI_SUB_CONFIGURE. > > I think the panic / test in sleepq_set_timeout_sbt is maybe overly > strong? !cold indicates the entire autoconfigure process has > concluded. But interrupts are available long before that. Seems like > hardclock is started at ~SI_SUB_CLOCKS? Which is admittedly after > DRIVERS, but still long before !cold. I'm not sure what set of > interrupt/timer functionality is needed for sleepq, but likely that > condition can be relaxed. > > If it cannot be relaxed enough for your driver, you could expand your > DRIVER_MODULE() into the expanded macro, replacing SI_SUB_DRIVERS with > a later stage. > > Afaik, only x86 enables interrupts before SI_SUB_CONFIGURE. Maybe sparc64 does too. Other arches do it as the last thing in SI_SUB_CONFIGURE, usually in a function named configure_final() in <arch>/autoconf.c. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?412537DD-D98F-4B92-85F5-CB93CF33F281>