[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/43587: stupid error message during boot from sysctl if no COMPAT40 in kernel
The following reply was made to PR bin/43587; it has been noted by GNATS.
From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@localhost>
Cc: gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
Subject: Re: bin/43587: stupid error message during boot from sysctl if no
COMPAT40 in kernel
Date: Fri, 09 Jul 2010 14:37:38 +0200
your aproach is good too.
Perhaps it is better to avoid an additional read of the old value in
case it mayy trigger some actions in the kernel.
remark: I'm not confirmed with the possibilities of the sysctl-interface
here. Perhaps this aspect is obsolete, because there may be no actions
inside of the kernel after a read.
But if some tries to set a value that does not fit into the variable
(e.g. string to long) shouldn't be silently ignored!
If it would be possible to catch exactly the read-only case of the
variable if the write fails, that should be the sollution.
Robert Elz wrote:
> The following reply was made to PR bin/43587; it has been noted by GNATS.
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Subject: Re: bin/43587: stupid error message during boot from sysctl if no
> COMPAT40 in kernel
> Date: Fri, 09 Jul 2010 18:49:41 +0700
> Date: Fri, 9 Jul 2010 10:20:01 +0000 (UTC)
> From: Wolfgang.Stukenbrock%nagler-company.com@localhost
> Message-ID: <20100709102001.394E863BAB7%www.NetBSD.org@localhost>
> Your #1 looks like a reasonable thing to do to me (sysctl nodes shouldn't
> exist unless the thing they control exists as well).
> | 2. keep sysctl from setting a variable to the same value with
> | it has before.
> In addition, I'd also fix sysctl, but not as you suggest there.
> Rather, just stop it issuing an error message when it attempts to
> set a variable (using ?=) and finds that the variable exists but
> cannot be set (for any reason, read-only being the most obvious).
> That I think is totally in keeping with the intent of the ?= operator,
> and allows the problem you observed to be "fixed" without needing to
> worry about testing whether the value being assigned is the same as the
> value there already (just doing the read to test that might cause side
> effects in some weird case) now worrying whether the write might be a
> in addition to setting the value.
Main Index |
Thread Index |