Date: Sun, 24 Apr 2011 13:10:26 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Doug Barton <dougb@freebsd.org> Cc: rc@freebsd.org, Rick Macklem <rmacklem@uoguelph.ca> Subject: Re: rc scripts change for review Message-ID: <20110424101026.GE48734@deviant.kiev.zoral.com.ua> In-Reply-To: <4DB3AA8C.7090003@FreeBSD.org> References: <1308036720.478939.1303598424273.JavaMail.root@erie.cs.uoguelph.ca> <4DB3AA8C.7090003@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ddcd+dsiJrvLd0CP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 23, 2011 at 09:43:56PM -0700, Doug Barton wrote: > On 04/23/2011 15:40, Rick Macklem wrote: > >> > >>>One thing I am not sure about is the REQUIRE: list in mountd. > >>>nfsserver and nfssrv essentially load the respective module. They > >>>are only > >>>used if sysctl variables need to be set and that's actually done by > >>>nfsd. > >>>(Should they be listed in mountd or nfsd or ???) > >> > >>It's not a good idea to add single scripts that only have a tiny > >>function, especially if they are only called conditionally (I.e., they > >>contain KEYWORD: nostart). It's preferred to handle these things > >>things > >>in the script that needs them, or if it's necessary in more than one > >>script to add a function to the appropriate .subr (rc, or network). > >> > >>So can you say a little more about what you're trying to accomplish? > >>It's not clear to me why instead of doing this: > >> > >>+ if ! sysctl vfs.newnfs>/dev/null 2>&1; then > >>+ force_depend nfssrv || return 1 > >>+ fi > >> > >>you would not just do this: > >> > >>+ if ! sysctl vfs.newnfs>/dev/null 2>&1; then > >>+ load_kld nfsd > >>+ fi > >> > >Well, the intent of the above was to get the module loaded so that > >sysctl could manipulate its sysctl variables. I played with it a bit > >and it turns out that neither of the above code snippets work in the > >sense that they don't affect the outcome. > > > >What is needed to make the sysctls work is "nfssrv" has to be in the > >REQUIRED: list for either mountd or nfsd. Without it, the sysctls fail > >with unknown oid. (I'm guessing there is some delay between the load_kld > >and when the module gets its sysctl variables registered?) > > > >Now, I'm not sure whether there is any advantage to specifying "nfssrv" > >in nfsd or mountd, although both seem to work when I test them. "nfsserv= er" > >is in mountd, so unless you guys have a better suggestion, that's where > >I'll leave it. >=20 > From what you're describing the reason it works by using the nfsserver=20 > and nfssrv scripts is simply an accident of timing. That's not a good=20 > thing no matter how you look at it. :) I understand your dilemma in=20 > that the nfsserver "solution" was pre-existing, so you were just=20 > following the example you had. However I have this odd idea that we=20 > ought to fix broken code, not perpetuate it. Even if I weren't=20 > interested in this for pedantic value, the fact that it's only working=20 > now as an accident of timing is a good reason to fix it. >=20 > The load_kld module is safe to run unconditionally (it will simply=20 > return if the module is loaded). So what you could do (for both cases)=20 > is something like this: >=20 > load_kld nfsd > while ! sysctl vfs.newnfs >/dev/null 2>&1; do > sleep .5 > done >=20 > If that works, I think we should add that feature to load_kld itself. This is a kludge, hiding some bug. Sysctl oids are registered synchronously, and kldload(2) syscall loads the module in context of the called thread. So if MOD_LOAD even handler registered its oids, then usermode and sysctl(8) should see them without arbitrary wait. --ddcd+dsiJrvLd0CP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2z9xIACgkQC3+MBN1Mb4iX5ACdHhw3eqWilCTp4EGG3kz4mQZU GZMAoL4eeLXptEvbZ0xzIhThItBwnH1c =6NTb -----END PGP SIGNATURE----- --ddcd+dsiJrvLd0CP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110424101026.GE48734>