Re: bin/43587: stupid error message during boot from sysctl if no COMPAT40 in kernel

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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
Cc: 
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>
     Message-ID:  <20100709125502.3746463BAB2%www.NetBSD.org@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 
from
   |  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
 is intended.
 
   |  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.
 
 Wolfgang.Stukenbrock%nagler-company.com@localhost said:
   |  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
 itself.
 
 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 ...
 
 kre