Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Sep 2000 16:34:46 -0400
From:      "Brian F. Feldman" <green@FreeBSD.org>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        Warner Losh <imp@village.org>, arch@FreeBSD.org, sjr@home.net
Subject:   Re: sysctl on boot. 
Message-ID:  <200009172034.e8HKYk525175@green.dyndns.org>
In-Reply-To: Message from Alfred Perlstein <bright@wintelcom.net>  of "Sun, 17 Sep 2000 12:34:32 PDT." <20000917123432.M15156@fw.wintelcom.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
> * Warner Losh <imp@village.org> [000917 12:04] wrote:
> > 
> > Stephen Roznowski reports in PR conf/19629 that there's a weakness in
> > /etc/rc.sysctl.  As it stands now, it runs early in the boot process.
> > And it needs to run early in the boot process for many sysctls.
> > However, there is a problem.  If you modload a driver or module after
> > this point, any variables set early in the boot process will not be
> > effective (because the setting fails).
> > 
> > A short term fix is to just rerun /etc/rc.sysctl at the end of the
> > boot sequence, just before the secrelevel change.  Stephen's PR
> > suggests this with a patch.  I think it is good, but wanted to get
> > some feedback from others before doing this.
> > 
> > A long term fix might be to give the kernel a memory so it can
> > initialize the sysctls from the get go.  However, that's much harder
> > to pull off and a whole lot more work.
> > 
> > Comments?
> 
> This is potentially dangerous as i'm not sure all sysctls are
> idempotent (sp?) meaning setting them twice can have weird
> effects, a solution might be to add another rc.sysctl2 or
> rc.sysctl.modules or something.

Yes, I agree with this.  I'd call them rc.sysctl (keep that the same) and 
rc.late_sysctl (which would run after most things as you propose, before the 
securelevel change).  You couldn't easily give the kernel a memory because 
the user might want sysctls in a specific order and you'd have to be able to 
record either the oid or the oid name for a given sysctl... and that 
wouldn't solve the problem of when to set them.

IOW, it would add complexity but not gain anything that postponing rc.sysctl 
or adding a secondary rc wouldn't gain.  So I wouldn't bother with that :)
You're making it seem like we need a registry.  I'd be a million times 
happier if a kldload(2) specified a hints file that could be used easily.


--
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green@FreeBSD.org                    `------------------------------'




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009172034.e8HKYk525175>