From owner-freebsd-rc@freebsd.org Sun Mar 31 21:00:45 2019 Return-Path: Delivered-To: freebsd-rc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F776156C3FB for ; Sun, 31 Mar 2019 21:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B621C9107D for ; Sun, 31 Mar 2019 21:00:44 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 76A96156C3F9; Sun, 31 Mar 2019 21:00:44 +0000 (UTC) Delivered-To: rc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65412156C3F8 for ; Sun, 31 Mar 2019 21:00:44 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0733391079 for ; Sun, 31 Mar 2019 21:00:44 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2AD41DF81 for ; Sun, 31 Mar 2019 21:00:43 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2VL0h2I011629 for ; Sun, 31 Mar 2019 21:00:43 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2VL0hwG011618 for rc@FreeBSD.org; Sun, 31 Mar 2019 21:00:43 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201903312100.x2VL0hwG011618@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: rc@FreeBSD.org Subject: Problem reports for rc@FreeBSD.org that need special attention Date: Sun, 31 Mar 2019 21:00:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 21:00:45 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 235122 | rc.subr limits call breaks non-root usage 1 problems total for which you should take action. From owner-freebsd-rc@freebsd.org Fri Apr 5 18:42:44 2019 Return-Path: Delivered-To: freebsd-rc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 277A1155699D for ; Fri, 5 Apr 2019 18:42:44 +0000 (UTC) (envelope-from crees@bayofrum.net) Received: from mail33c50.megamailservers.eu (mail163c50.megamailservers.eu [91.136.10.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79FC86ED97 for ; Fri, 5 Apr 2019 18:42:41 +0000 (UTC) (envelope-from crees@bayofrum.net) X-Authenticated-User: bayofrum@uwclub.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1554489441; bh=RLihil8OcDTNckSw+9reczbuK0eVAXppF/FRTIqCHa0=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=oLPpdxQhNTZODUHdiW252yExOF3kAkGyf0waTIs1i5APMxuWWROlmSstQr00PexTY tra0ShVsW7lROUeOCgWJSpJVPNGbw9fMNzeUZt/W/O6ZdRvzLLIqxpmmfGM1KovzTd smTkJMmCkkxuF1JBm0hIJ5oGugylid0ftgKNGBZs= Feedback-ID: crees@bayofrum. Received: from pegasus.bayofrum.net (81-178-238-70.dsl.pipex.com [81.178.238.70]) (authenticated bits=0) by mail33c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x35IbJjK016990; Fri, 5 Apr 2019 18:37:21 +0000 Received: from R.bayofrum.net (R.bayofrum.net [192.168.1.129]) by pegasus.bayofrum.net (Postfix) with ESMTPSA id 5F9BECEEF; Fri, 5 Apr 2019 19:37:11 +0100 (BST) Date: Fri, 05 Apr 2019 19:37:16 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <20181225074145.GA60291@kib.kiev.ua> References: <9f786428-7fea-4fa4-a29e-ed91997a87fd@email.android.com> <20181224133721.GW60291@kib.kiev.ua> <20181224165023.GY60291@kib.kiev.ua> <20181225074145.GA60291@kib.kiev.ua> MIME-Version: 1.0 Subject: Re: svn commit: r342389 - head/share/man/man5 To: Konstantin Belousov , Chris Rees CC: freebsd-rc@freebsd.org From: Chris Rees Message-ID: <120E994C-79DE-46E2-AAB7-649E4929AFE9@bayofrum.net> X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: 5F9BECEEF.AEBF8 X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@bayofrum.net X-Spam-Status: No X-CTCH-RefID: str=0001.0A0B020C.5CA7A061.0026, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=eOw9ckh1 c=1 sm=1 tr=0 a=i0HMBnJGy7D3/NFKO8d8XA==:117 a=i0HMBnJGy7D3/NFKO8d8XA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=oexKYjalfGEA:10 a=ZB5LerlCAAAA:8 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=Zh0ublit3hlReUIAKg4A:9 a=IHEb_aTBH0utfAYF:21 a=km0VK683llT37aLa:21 a=QEXdDO2ut3YA:10 a=P0S6o3SJAAAA:8 a=UCBx1uGqF50gFMD534wA:9 a=d3WRF4F4032qF5a9:21 a=tP_O5BDVVbRJCbk7:21 a=DqoLPUHcV2BExSCQ:21 a=_W_S_7VecoQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=YKPTzOroS2oaEK2QgPcx:22 a=IjZwj45LgO3ly-622nXo:22 a=WH_0ghv6r2uJcVQkXlWi:22 X-Rspamd-Queue-Id: 79FC86ED97 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=fail (rsa verify failed) header.d=megamailservers.eu header.s=maildub header.b=oLPpdxQh X-Spamd-Result: default: False [-1.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_DKIM_REJECT(1.00)[megamailservers.eu:s=maildub]; URI_COUNT_ODD(1.00)[9]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[megamailservers.eu:-]; MX_GOOD(-0.01)[www.bayofrum.net]; NEURAL_HAM_SHORT(-0.90)[-0.903,0]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[70.238.178.81.zen.spamhaus.org : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:9115, ipnet:91.136.0.0/17, country:GB]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[173.10.136.91.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.970,0]; IP_SCORE(-0.46)[ipnet: 91.136.0.0/17(-1.23), asn: 9115(-0.99), country: GB(-0.09)]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[bayofrum.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 18:42:44 -0000 Hello RC people, Konstantin has kindly reviewed the patch to fix load_kld behaviour, but wou= ld prefer that someone more familiar with RC give me approval to commit. I= haven't stripped any of the replies, so the conversation should be fairly = easy to follow, though I'm happy to link to archives if anyone missed it. Please would someone review and approve? https://www.bayofrum.net/~crees/patches/rc-kld_list-extension-2.diff Thanks! Chris On 25 December 2018 07:41:45 GMT, Konstantin Belousov = wrote: >On Mon, Dec 24, 2018 at 06:56:40PM +0000, Chris Rees wrote: >> On 24/12/2018 16:50, Konstantin Belousov wrote: >> > On Mon, Dec 24, 2018 at 03:34:57PM +0000, Chris Rees wrote: >> >> On 24/12/2018 13:37, Konstantin Belousov wrote: >> >>> On Mon, Dec 24, 2018 at 01:07:54PM +0000, Chris Rees wrote: >> >>>> On 24/12/2018 11:23, Chris Rees wrote: >> >>>>> On 24 Dec 2018 11:17, Konstantin Belousov >wrote: >> >>>>> >> >>>>> On Mon, Dec 24, 2018 at 10:47:48AM +0000, Chris Rees wrote: >> >>>>> > Author: crees (doc,ports committer) >> >>>>> > Date: Mon Dec 24 10:47:48 2018 >> >>>>> > New Revision: 342389 >> >>>>> > URL: https://svnweb.freebsd.org/changeset/base/342389 >> >>>>> > >> >>>>> > Log: >> >>>>> >=C2=A0=C2=A0 Clarify kld_list format >> >>>>> >=C2=A0=C2=A0 >> >>>>> >=C2=A0=C2=A0 PR: docs/234248 >> >>>>> >=C2=A0=C2=A0 Submitted by: David Fiander >> >>>>> >=C2=A0=C2=A0 Submitted by: Miroslav Lachman >> >>>>> > >> >>>>> > Modified: >> >>>>> >=C2=A0=C2=A0 head/share/man/man5/rc.conf.5 >> >>>>> > >> >>>>> > Modified: head/share/man/man5/rc.conf.5 >> >>>>> > >> >>>>>=20=20=20=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> >>>>> > --- head/share/man/man5/rc.conf.5 Mon Dec 24 06:14:32 >2018 >> >>>>> (r342388) >> >>>>> > +++ head/share/man/man5/rc.conf.5 Mon Dec 24 10:47:48 >2018 >> >>>>> (r342389) >> >>>>> > @@ -248,12 +248,14 @@ Default >> >>>>> >=C2=A0 .Pa /etc/ddb.conf . >> >>>>> >=C2=A0 .It Va kld_list >> >>>>> >=C2=A0 .Pq Vt str >> >>>>> > -A list of kernel modules to load right after the local >> >>>>> > -disks are mounted. >> >>>>> > +A whitespace-separated list of kernel modules to load >right after >> >>>>> > +the local disks are mounted, without any >> >>>>> > +.Pa .ko >> >>>>> > +extension or path. >> >>>>> I think both extension and path are accepted if supplied. >> >>>>> It is the behaviour described in kldload(8). >> >>>>> >> >>>>> >> >>>>> That's true, but the kld rc script adds .ko, so providing the >> >>>>> extension will probably break, and it checks for existing >modules >> >>>>> using the provided name as a regex, so that will also fail. >> >>>>> >> >>>>> I don't think that'd be hard to fix though, so I'll fix that >and put a >> >>>>> patch up for review later. >> >>>> Having looked again, rc.subr uses kldstat -v, so the path is >indeed not >> >>>> a problem, but the extension is-- removing any extension from >_kld will >> >>>> ensure that it will always match correctly.=C2=A0 At the moment it = is >> >>>> fragile, because it will load correctly the first time but hit >an error >> >>>> if the user has put the extension in and the module is already >loaded. >> >>>> >> >>>> @RC people, does this look acceptable (I'll need approval >please)? >> >>>> >> >>>> >https://www.bayofrum.net/~crees/patches/rc-kld_list-extension.diff >> >>> I do not quite see a point in the check for the module presence. >> >>> Kernel already rejects already loaded modules (by module name). >> >> True; this code predates the -n option to kldload.=C2=A0 Using that >makes the >> >> whole checking unnecessary. >> >> >> >> How about this one? >> >> >> >> >https://www.bayofrum.net/~crees/patches/rc-kld_list-extension-2.diff >> > It looks reasonable to me. I am not sure if we want to keep the >options >> > for load_kld for benefit of the third-party scripts, or not. E.g. >we can >> > silently ignore them. >>=20 >> Yeah, my patch ignores them silently.=C2=A0 It has the added bonus of not >> needing to sweep the ports tree, with all the version issues that >> entails as the behaviour has slightly changed if the options are >> necessary at that point. >>=20 >> > How was this tested ? >> [crees@pegasus]~/workspace/src/head% sudo sh >> # . libexec/rc/rc.subr >> # kldstat |grep cuse >> # load_kld cuse4bsd >> # kldstat |grep cuse >> 15=C2=A0=C2=A0=C2=A0 1 0xffffffff818c3000 40a0=C2=A0=C2=A0=C2=A0=C2=A0 c= use.ko >> # load_kld cuse4bsd >> # load_kld doesntexist >> kldload: can't load doesntexist: No such file or directory >> sh: WARNING: Unable to load kernel module doesntexist >> # kldunload cuse >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko >> # kldstat |grep cuse >> 15=C2=A0=C2=A0=C2=A0 1 0xffffffff818c3000 4c80=C2=A0=C2=A0=C2=A0=C2=A0 c= use4bsd.ko >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko >> # kldstat |grep cuse >> 15=C2=A0=C2=A0=C2=A0 1 0xffffffff818c3000 4c80=C2=A0=C2=A0=C2=A0=C2=A0 c= use4bsd.ko >I suppose escapes are something that your mail agent inserted and not >the >actual system output. > >The script looks fine to me, but I am not the right person to stamp the >approval on the rc changes. > >> # >>=20 >> It's rather a curiosity for me that cuse4bsd only loads as itself if >> called by path, but it doesn't happen with any other modules-- this >was >> just to prove that full paths and extensions work correctly as >> intended.=C2=A0 My machine also boots fine. >>=20 >> Can you think of any other behaviour I'd need to check? >No, for me it looks good enough. > >--=20 >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. --=20 Sent from my Android device with K-9 Mail. Please excuse my brevity. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-rc@freebsd.org Fri Apr 5 19:28:13 2019 Return-Path: Delivered-To: freebsd-rc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3113155B3DA for ; Fri, 5 Apr 2019 19:28:13 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 858E470A7C for ; Fri, 5 Apr 2019 19:28:12 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x35JS6Y3040778; Fri, 5 Apr 2019 12:28:06 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x35JS6G4040777; Fri, 5 Apr 2019 12:28:06 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201904051928.x35JS6G4040777@gndrsh.dnsmgr.net> Subject: Re: svn commit: r342389 - head/share/man/man5 In-Reply-To: <120E994C-79DE-46E2-AAB7-649E4929AFE9@bayofrum.net> To: Chris Rees Date: Fri, 5 Apr 2019 12:28:06 -0700 (PDT) CC: Konstantin Belousov , Chris Rees , freebsd-rc@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 858E470A7C X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.32 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(0.03)[ip: (0.12), ipnet: 69.59.192.0/19(0.06), asn: 13868(0.04), country: US(-0.06)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.09)[0.092,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.12)[0.119,0]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.19)[0.187,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 19:28:14 -0000 > Hello RC people, > > Konstantin has kindly reviewed the patch to fix load_kld behaviour, but would prefer that someone more familiar with RC give me approval to commit. I haven't stripped any of the replies, so the conversation should be fairly easy to follow, though I'm happy to link to archives if anyone missed it. > > Please would someone review and approve? > > https://www.bayofrum.net/~crees/patches/rc-kld_list-extension-2.diff Can we please either have this up in phabricator, or have permission to pull your diff into a phabricator review if you do not want to do it yourself. We do not need the comments and exchange of emails, just the diffs. http://reviews.freebsd.org Thanks, Rod > Thanks! > > Chris > > On 25 December 2018 07:41:45 GMT, Konstantin Belousov wrote: > >On Mon, Dec 24, 2018 at 06:56:40PM +0000, Chris Rees wrote: > >> On 24/12/2018 16:50, Konstantin Belousov wrote: > >> > On Mon, Dec 24, 2018 at 03:34:57PM +0000, Chris Rees wrote: > >> >> On 24/12/2018 13:37, Konstantin Belousov wrote: > >> >>> On Mon, Dec 24, 2018 at 01:07:54PM +0000, Chris Rees wrote: > >> >>>> On 24/12/2018 11:23, Chris Rees wrote: > >> >>>>> On 24 Dec 2018 11:17, Konstantin Belousov > >wrote: > >> >>>>> > >> >>>>> On Mon, Dec 24, 2018 at 10:47:48AM +0000, Chris Rees wrote: > >> >>>>> > Author: crees (doc,ports committer) > >> >>>>> > Date: Mon Dec 24 10:47:48 2018 > >> >>>>> > New Revision: 342389 > >> >>>>> > URL: https://svnweb.freebsd.org/changeset/base/342389 > >> >>>>> > > >> >>>>> > Log: > >> >>>>> >?? Clarify kld_list format > >> >>>>> >?? > >> >>>>> >?? PR: docs/234248 > >> >>>>> >?? Submitted by: David Fiander > >> >>>>> >?? Submitted by: Miroslav Lachman > >> >>>>> > > >> >>>>> > Modified: > >> >>>>> >?? head/share/man/man5/rc.conf.5 > >> >>>>> > > >> >>>>> > Modified: head/share/man/man5/rc.conf.5 > >> >>>>> > > >> >>>>> > >============================================================================== > >> >>>>> > --- head/share/man/man5/rc.conf.5 Mon Dec 24 06:14:32 > >2018 > >> >>>>> (r342388) > >> >>>>> > +++ head/share/man/man5/rc.conf.5 Mon Dec 24 10:47:48 > >2018 > >> >>>>> (r342389) > >> >>>>> > @@ -248,12 +248,14 @@ Default > >> >>>>> >? .Pa /etc/ddb.conf . > >> >>>>> >? .It Va kld_list > >> >>>>> >? .Pq Vt str > >> >>>>> > -A list of kernel modules to load right after the local > >> >>>>> > -disks are mounted. > >> >>>>> > +A whitespace-separated list of kernel modules to load > >right after > >> >>>>> > +the local disks are mounted, without any > >> >>>>> > +.Pa .ko > >> >>>>> > +extension or path. > >> >>>>> I think both extension and path are accepted if supplied. > >> >>>>> It is the behaviour described in kldload(8). > >> >>>>> > >> >>>>> > >> >>>>> That's true, but the kld rc script adds .ko, so providing the > >> >>>>> extension will probably break, and it checks for existing > >modules > >> >>>>> using the provided name as a regex, so that will also fail. > >> >>>>> > >> >>>>> I don't think that'd be hard to fix though, so I'll fix that > >and put a > >> >>>>> patch up for review later. > >> >>>> Having looked again, rc.subr uses kldstat -v, so the path is > >indeed not > >> >>>> a problem, but the extension is-- removing any extension from > >_kld will > >> >>>> ensure that it will always match correctly.? At the moment it is > >> >>>> fragile, because it will load correctly the first time but hit > >an error > >> >>>> if the user has put the extension in and the module is already > >loaded. > >> >>>> > >> >>>> @RC people, does this look acceptable (I'll need approval > >please)? > >> >>>> > >> >>>> > >https://www.bayofrum.net/~crees/patches/rc-kld_list-extension.diff > >> >>> I do not quite see a point in the check for the module presence. > >> >>> Kernel already rejects already loaded modules (by module name). > >> >> True; this code predates the -n option to kldload.? Using that > >makes the > >> >> whole checking unnecessary. > >> >> > >> >> How about this one? > >> >> > >> >> > >https://www.bayofrum.net/~crees/patches/rc-kld_list-extension-2.diff > >> > It looks reasonable to me. I am not sure if we want to keep the > >options > >> > for load_kld for benefit of the third-party scripts, or not. E.g. > >we can > >> > silently ignore them. > >> > >> Yeah, my patch ignores them silently.? It has the added bonus of not > >> needing to sweep the ports tree, with all the version issues that > >> entails as the behaviour has slightly changed if the options are > >> necessary at that point. > >> > >> > How was this tested ? > >> [crees@pegasus]~/workspace/src/head% sudo sh > >> # . libexec/rc/rc.subr > >> # kldstat |grep cuse > >> # load_kld cuse4bsd > >> # kldstat |grep cuse > >> 15??? 1 0xffffffff818c3000 40a0???? cuse.ko > >> # load_kld cuse4bsd > >> # load_kld doesntexist > >> kldload: can't load doesntexist: No such file or directory > >> sh: WARNING: Unable to load kernel module doesntexist > >> # kldunload cuse > >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko > >> # kldstat |grep cuse > >> 15??? 1 0xffffffff818c3000 4c80???? cuse4bsd.ko > >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko > >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko > >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko > >> # kldstat |grep cuse > >> 15??? 1 0xffffffff818c3000 4c80???? cuse4bsd.ko > >I suppose escapes are something that your mail agent inserted and not > >the > >actual system output. > > > >The script looks fine to me, but I am not the right person to stamp the > >approval on the rc changes. > > > >> # > >> > >> It's rather a curiosity for me that cuse4bsd only loads as itself if > >> called by path, but it doesn't happen with any other modules-- this > >was > >> just to prove that full paths and extensions work correctly as > >> intended.? My machine also boots fine. > >> > >> Can you think of any other behaviour I'd need to check? > >No, for me it looks good enough. > > > >-- > >This message has been scanned for viruses and > >dangerous content by MailScanner, and is > >believed to be clean. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > freebsd-rc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-rc@freebsd.org Fri Apr 5 20:42:27 2019 Return-Path: Delivered-To: freebsd-rc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E91C155E2AE for ; Fri, 5 Apr 2019 20:42:27 +0000 (UTC) (envelope-from crees@bayofrum.net) Received: from mail51c50.megamailservers.eu (mail167c50.megamailservers.eu [91.136.10.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8C4574CD9 for ; Fri, 5 Apr 2019 20:42:25 +0000 (UTC) (envelope-from crees@bayofrum.net) X-Authenticated-User: bayofrum@uwclub.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1554496745; bh=ZdCWR5hVXD97UOb07cjKtBrohNSZee8zUSTDRTdVDvk=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=g0Kc1G+MMwJfQ/07IMBXnQ2LUWUd2Gyzu899LIjpyUOcR2OlUWfPW7aMjm981RzKW vGDBvx1Q9PQQmfDpCiL9sGVZpgiScOUiDagL+xWrdVlSUhf0fZSrBvp80U/f8MOC+q PN4feT1zGDtlJ52T5fw666Dw69gOhKQuOQwHZ6ms= Feedback-ID: crees@bayofrum. Received: from pegasus.bayofrum.net (81-178-238-70.dsl.pipex.com [81.178.238.70]) (authenticated bits=0) by mail51c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x35Kd3c3010730; Fri, 5 Apr 2019 20:39:04 +0000 Received: from R.bayofrum.net (R.bayofrum.net [192.168.1.129]) by pegasus.bayofrum.net (Postfix) with ESMTPSA id 4D60BD397; Fri, 5 Apr 2019 21:38:49 +0100 (BST) Date: Fri, 05 Apr 2019 21:38:53 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <201904051928.x35JS6G4040777@gndrsh.dnsmgr.net> References: <201904051928.x35JS6G4040777@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: svn commit: r342389 - head/share/man/man5 To: "Rodney W. Grimes" CC: Konstantin Belousov , Chris Rees , freebsd-rc@freebsd.org From: Chris Rees Message-ID: <1A8A6650-A498-465C-A3EF-F82BAC0B8F21@bayofrum.net> X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: 4D60BD397.A8B86 X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@bayofrum.net X-Spam-Status: No X-CTCH-RefID: str=0001.0A0B0214.5CA7BCE9.0025, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=G6Uy7es5 c=1 sm=1 tr=0 a=i0HMBnJGy7D3/NFKO8d8XA==:117 a=i0HMBnJGy7D3/NFKO8d8XA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=oexKYjalfGEA:10 a=iKhvJSA4AAAA:8 a=ZB5LerlCAAAA:8 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=pz6rhnZqCJhXmXK6IdgA:9 a=ZZqB9Ryba1_m7FQk:21 a=3QY9xNNaV7b9Jl-4:21 a=QEXdDO2ut3YA:10 a=odh9cflL3HIXMm4fY7Wr:22 a=YKPTzOroS2oaEK2QgPcx:22 a=IjZwj45LgO3ly-622nXo:22 X-Rspamd-Queue-Id: C8C4574CD9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=fail (rsa verify failed) header.d=megamailservers.eu header.s=maildub header.b=g0Kc1G+M X-Spamd-Result: default: False [-2.53 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[70.238.178.81.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_DKIM_REJECT(1.00)[megamailservers.eu:s=maildub]; IP_SCORE(-0.47)[ipnet: 91.136.0.0/17(-1.25), asn: 9115(-1.00), country: GB(-0.09)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bayofrum.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: www.bayofrum.net]; DKIM_TRACE(0.00)[megamailservers.eu:-]; NEURAL_HAM_SHORT(-0.85)[-0.853,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:9115, ipnet:91.136.0.0/17, country:GB]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[177.10.136.91.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 20:42:27 -0000 Hi Rod, On 5 April 2019 20:28:06 BST, "Rodney W. Grimes" wrote: >> Hello RC people, >>=20 >> Konstantin has kindly reviewed the patch to fix load_kld behaviour, >but would prefer that someone more familiar with RC give me approval to >commit. I haven't stripped any of the replies, so the conversation >should be fairly easy to follow, though I'm happy to link to archives >if anyone missed it. >>=20 >> Please would someone review and approve? >>=20 >> https://www.bayofrum.net/~crees/patches/rc-kld_list-extension-2.diff > >Can we please either have this up in phabricator, or have permission >to pull your diff into a phabricator review if you do not want to >do it yourself. > >We do not need the comments and exchange of emails, >just the diffs. > >http://reviews.freebsd.org > https://reviews.freebsd.org/D18670 Appears I'd forgotten it was there- it would be great to have an 'RC' group= to review in phabricator. Cheers, Chris=20 > >> Thanks! >>=20 >> Chris >>=20 >> On 25 December 2018 07:41:45 GMT, Konstantin Belousov > wrote: >> >On Mon, Dec 24, 2018 at 06:56:40PM +0000, Chris Rees wrote: >> >> On 24/12/2018 16:50, Konstantin Belousov wrote: >> >> > On Mon, Dec 24, 2018 at 03:34:57PM +0000, Chris Rees wrote: >> >> >> On 24/12/2018 13:37, Konstantin Belousov wrote: >> >> >>> On Mon, Dec 24, 2018 at 01:07:54PM +0000, Chris Rees wrote: >> >> >>>> On 24/12/2018 11:23, Chris Rees wrote: >> >> >>>>> On 24 Dec 2018 11:17, Konstantin Belousov > >> >wrote: >> >> >>>>> >> >> >>>>> On Mon, Dec 24, 2018 at 10:47:48AM +0000, Chris Rees >wrote: >> >> >>>>> > Author: crees (doc,ports committer) >> >> >>>>> > Date: Mon Dec 24 10:47:48 2018 >> >> >>>>> > New Revision: 342389 >> >> >>>>> > URL: https://svnweb.freebsd.org/changeset/base/342389 >> >> >>>>> > >> >> >>>>> > Log: >> >> >>>>> >?? Clarify kld_list format >> >> >>>>> >?? >> >> >>>>> >?? PR: docs/234248 >> >> >>>>> >?? Submitted by: David Fiander >> >> >>>>> >?? Submitted by: Miroslav Lachman >> >> >>>>> > >> >> >>>>> > Modified: >> >> >>>>> >?? head/share/man/man5/rc.conf.5 >> >> >>>>> > >> >> >>>>> > Modified: head/share/man/man5/rc.conf.5 >> >> >>>>> > >> >> >>>>>=20=20=20=20 >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> >> >>>>> > --- head/share/man/man5/rc.conf.5 Mon Dec 24 06:14:32 >> >2018 >> >> >>>>> (r342388) >> >> >>>>> > +++ head/share/man/man5/rc.conf.5 Mon Dec 24 10:47:48 >> >2018 >> >> >>>>> (r342389) >> >> >>>>> > @@ -248,12 +248,14 @@ Default >> >> >>>>> >? .Pa /etc/ddb.conf . >> >> >>>>> >? .It Va kld_list >> >> >>>>> >? .Pq Vt str >> >> >>>>> > -A list of kernel modules to load right after the >local >> >> >>>>> > -disks are mounted. >> >> >>>>> > +A whitespace-separated list of kernel modules to load >> >right after >> >> >>>>> > +the local disks are mounted, without any >> >> >>>>> > +.Pa .ko >> >> >>>>> > +extension or path. >> >> >>>>> I think both extension and path are accepted if >supplied. >> >> >>>>> It is the behaviour described in kldload(8). >> >> >>>>> >> >> >>>>> >> >> >>>>> That's true, but the kld rc script adds .ko, so providing >the >> >> >>>>> extension will probably break, and it checks for existing >> >modules >> >> >>>>> using the provided name as a regex, so that will also fail. >> >> >>>>> >> >> >>>>> I don't think that'd be hard to fix though, so I'll fix that >> >and put a >> >> >>>>> patch up for review later. >> >> >>>> Having looked again, rc.subr uses kldstat -v, so the path is >> >indeed not >> >> >>>> a problem, but the extension is-- removing any extension from >> >_kld will >> >> >>>> ensure that it will always match correctly.? At the moment it >is >> >> >>>> fragile, because it will load correctly the first time but >hit >> >an error >> >> >>>> if the user has put the extension in and the module is >already >> >loaded. >> >> >>>> >> >> >>>> @RC people, does this look acceptable (I'll need approval >> >please)? >> >> >>>> >> >> >>>> >> >https://www.bayofrum.net/~crees/patches/rc-kld_list-extension.diff >> >> >>> I do not quite see a point in the check for the module >presence. >> >> >>> Kernel already rejects already loaded modules (by module >name). >> >> >> True; this code predates the -n option to kldload.? Using that >> >makes the >> >> >> whole checking unnecessary. >> >> >> >> >> >> How about this one? >> >> >> >> >> >> >> >https://www.bayofrum.net/~crees/patches/rc-kld_list-extension-2.diff >> >> > It looks reasonable to me. I am not sure if we want to keep the >> >options >> >> > for load_kld for benefit of the third-party scripts, or not.=20 >E.g. >> >we can >> >> > silently ignore them. >> >>=20 >> >> Yeah, my patch ignores them silently.? It has the added bonus of >not >> >> needing to sweep the ports tree, with all the version issues that >> >> entails as the behaviour has slightly changed if the options are >> >> necessary at that point. >> >>=20 >> >> > How was this tested ? >> >> [crees@pegasus]~/workspace/src/head% sudo sh >> >> # . libexec/rc/rc.subr >> >> # kldstat |grep cuse >> >> # load_kld cuse4bsd >> >> # kldstat |grep cuse >> >> 15??? 1 0xffffffff818c3000 40a0???? cuse.ko >> >> # load_kld cuse4bsd >> >> # load_kld doesntexist >> >> kldload: can't load doesntexist: No such file or directory >> >> sh: WARNING: Unable to load kernel module doesntexist >> >> # kldunload cuse >> >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko >> >> # kldstat |grep cuse >> >> 15??? 1 0xffffffff818c3000 4c80???? cuse4bsd.ko >> >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko >> >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko >> >> # load_kld -m nothing -e noop /boot/modules/cuse4bsd.ko >> >> # kldstat |grep cuse >> >> 15??? 1 0xffffffff818c3000 4c80???? cuse4bsd.ko >> >I suppose escapes are something that your mail agent inserted and >not >> >the >> >actual system output. >> > >> >The script looks fine to me, but I am not the right person to stamp >the >> >approval on the rc changes. >> > >> >> # >> >>=20 >> >> It's rather a curiosity for me that cuse4bsd only loads as itself >if >> >> called by path, but it doesn't happen with any other modules-- >this >> >was >> >> just to prove that full paths and extensions work correctly as >> >> intended.? My machine also boots fine. >> >>=20 >> >> Can you think of any other behaviour I'd need to check? >> >No, for me it looks good enough. >> > >> >--=20 >> >This message has been scanned for viruses and >> >dangerous content by MailScanner, and is >> >believed to be clean. >>=20 >> --=20 >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> --=20 >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >>=20 >> _______________________________________________ >> freebsd-rc@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-rc >> To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" >>=20 >>=20 --=20 Sent from my Android device with K-9 Mail. Please excuse my brevity. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.