[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: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: bin/43587: stupid error message during boot from sysctl if no
COMPAT40 in kernel
Date: Fri, 09 Jul 2010 20:30:51 +0700
Date: Fri, 9 Jul 2010 12:55:02 +0000 (UTC)
From: Martin Husemann <martin%duskware.de@localhost>
| I suggested the test for the same value because I'd like to see a warning
| if - for whatever reason - the values configured in sysctl.conf differ
| the ones in effect on the system.
I understand what you're saying, but I don't think that makes sense here.
Ideally, what would have happened, is that the sysctl node simply wouldn't
exist, and in that case sysctl(8) (using ?=) would have been silent. No
warnings about nodes that couldnt be set/changed/... That is exactly as
| The admin can edit the .conf file anyway,
Yes, exactly - that's the point, if this is a setting that you want to have
happen, then you should be using the '=' operator, not '?=' - then you'll get
warnings (errors, whatever you want to call them) if for any reason the
setting doesn't happen. That is as it should be.
The ?= settings are (primarily) for stuff NetBSD is distributing [Aside: I
should launch another diatribe here about yet another user config file now
being corrupted with distribution settings - but I won't - today] that should
apply when it makes sense for them to apply, and should b silently ignored
in any other case.
| 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!
In sysctl(8) I don't think that's a problem it makes sense to worry
about - or not in the relevant place - the data type comes from the
sysctl mib, the code cannot be attempting to set the "wrong" type, nor
anything else like that.
If that kind of error was going to occur, and be detected, it would be
where the user's arg value is being converted from the argv string to
the appropriate data type to store, not when the store operation happens
But if you really wanted to allow for that kind of error occurring, then
instead of just ignoring the error, you could test errno and ignore the
error codes that just mean "not possible now" rather than "you botched it"
just in case one of the latter type ever did happen (from the man page
(sysctl(3)) it appears that ignoring errors when errno is any of ENOENT,
EOPNOTSUPP, or EPERM would probably be sufficient.
As another side issue, I did think it slightly odd that in a patch intended
to make sysctl quiet, it was reading the old value of the node (and like you,
I have no idea if that is ever going to be a problem in practice) and if
that failed, issuing an error message ...
Main Index |
Thread Index |