Re: sysctl(3)
Hi, On Fri, 12.03.2010 at 13:21:45 +0001, Jason McIntyre wrote: > On Thu, Mar 11, 2010 at 12:23:22AM +0100, Toni Mueller wrote: > > > what exactly is missing from sysctl(3)? > > the sections I read seem to exhaustively list the settings that can > > be used with the 'mib' parameter, but not for PF_KEY. > ok, PF_KEY is now documented. thank you! -- Kind regards, --Toni++
Re: sysctl(3)
On Thu, Mar 11, 2010 at 12:23:22AM +0100, Toni Mueller wrote: > > what exactly is missing from sysctl(3)? > > the sections I read seem to exhaustively list the settings that can > be used with the 'mib' parameter, but not for PF_KEY. > ok, PF_KEY is now documented. jmc
Re: sysctl(3)
On Thu, Mar 11, 2010 at 05:22:39PM +0001, Jason McIntyre wrote: > On Thu, Mar 11, 2010 at 06:02:49PM +0100, Toni Mueller wrote: > > On Thu, 11.03.2010 at 14:31:46 +0100, Toni Mueller > > wrote: > > > But I'll now grab 'comp' too and see if that helps. > > > > I've now looked at the man page in -current, and it does not cover the > > "leaves" below PF_KEY. > > > > i think otto meant only about the missing page, not the PF_KEY stuff. > that is currently documented, but we're working on a fix... > er, undocumented rather. jmc
Re: sysctl(3)
On Thu, Mar 11, 2010 at 06:02:49PM +0100, Toni Mueller wrote: > On Thu, 11.03.2010 at 14:31:46 +0100, Toni Mueller > wrote: > > But I'll now grab 'comp' too and see if that helps. > > I've now looked at the man page in -current, and it does not cover the > "leaves" below PF_KEY. > i think otto meant only about the missing page, not the PF_KEY stuff. that is currently documented, but we're working on a fix... jmc
Re: sysctl(3)
On Thu, 11.03.2010 at 14:31:46 +0100, Toni Mueller wrote: > But I'll now grab 'comp' too and see if that helps. I've now looked at the man page in -current, and it does not cover the "leaves" below PF_KEY. -- Kind regards, --Toni++
Re: sysctl(3)
Hi Otto, On Thu, 11.03.2010 at 07:08:24 +0100, Otto Moerbeek wrote: > On Thu, Mar 11, 2010 at 12:23:22AM +0100, Toni Mueller wrote: > > Btw, in the snapshot of today, the sysctl(3) man page is absent: > > > > $ find . -name 'sysctl*' > > ./cat8/sysctl.0 > > ./cat5/sysctl.conf.0 > > $ > > Did you install the comp set? It's in there: > $ tar ztf comp47.tgz | grep syscl > ./usr/include/sys/sysctl.h > ./usr/share/man/cat3/sysctl.0 thanks for the heads-up! No, I only installed the 'man' package on a different machine than the one I am working on (not OpenBSD, either). But I'll now grab 'comp' too and see if that helps. -- Kind regards, --Toni++
Re: sysctl(3)
On Thu, Mar 11, 2010 at 12:23:22AM +0100, Toni Mueller wrote: > Hi, > > On Wed, 10.03.2010 at 21:48:38 +0001, Jason McIntyre > wrote: > > what exactly is missing from sysctl(3)? > > the sections I read seem to exhaustively list the settings that can > be used with the 'mib' parameter, but not for PF_KEY. > > Btw, in the snapshot of today, the sysctl(3) man page is absent: > > $ find . -name 'sysctl*' > ./cat8/sysctl.0 > ./cat5/sysctl.conf.0 > $ Did you install the comp set? It's in there: $ tar ztf comp47.tgz | grep syscl ./usr/include/sys/sysctl.h ./usr/share/man/cat3/sysctl.0 ... > > > as to why the cgi thing returns the section page, i'll let someone else > > explain (i.e. i don't know). > > Thanks. > > -- > Kind regards, > --Toni++
Re: sysctl(3)
Hi, On Wed, 10.03.2010 at 21:48:38 +0001, Jason McIntyre wrote: > what exactly is missing from sysctl(3)? the sections I read seem to exhaustively list the settings that can be used with the 'mib' parameter, but not for PF_KEY. Btw, in the snapshot of today, the sysctl(3) man page is absent: $ find . -name 'sysctl*' ./cat8/sysctl.0 ./cat5/sysctl.conf.0 $ > as to why the cgi thing returns the section page, i'll let someone else > explain (i.e. i don't know). Thanks. -- Kind regards, --Toni++
Re: sysctl(3)
On Wed, Mar 10, 2010 at 09:42:30PM +0100, Toni Mueller wrote: > Hi, > > while digging into my problem with bogus SADB entries, I noticed that > sysctl(3) is incomplete, and the online man page doesn't show up (I only > get sysctl(8) to see when accessing this link: > http://www.openbsd.org/cgi-bin/man.cgi?query=sysctl&apropos=0&sektion=3&manpath=OpenBSD+Current&arch=i386&format=html > ). If someone with appropriate knowledge and powers > could fix these problems, eg. before 4.7, that would be great. > what exactly is missing from sysctl(3)? as to why the cgi thing returns the section page, i'll let someone else explain (i.e. i don't know). jmc
Re: sysctl(3) and iteration over HW_SENSORS
On 11/07/06, Weldon Goree <[EMAIL PROTECTED]> wrote: According to the source, `/sbin/sysctl hw.sensors` calls its own main parsing routine 256 times to check each of the 256 possible sensors and allocates its own list from the results. Eek. Since I'm just writing a Yes, I thought the same thing the first time I encountered it. Plus you have to remember the fact that sysctl(3) has to go through the whole linked list once again to find the last sensor even if you call it in strictly increasing order, and it also has to go through the whole linked list to conclude about the non-existence of a sensor. If I remember my Analysis of Algorithms class correctly, this might mean that the complexity of the sysctl(3) approach in populating a userspace array with sensors is about n*m if n goes to infinity for m less than or equal to n, where n is the maximum possible number of sensors, and m is the actual number of elements in the sensors linked list. But the thing is, n could not go to infinity because it's a constant that stays at 256, and m usually varies in around 12 to 64, so at the end of the day, it doesn't make sysctl(3)/sysctl(8) any noticeably slower, does it? :) voltage monitor I suppose I could have it do that once on init and then just monitor the specific sensors it finds relevant, assuming I can convince myself that the numbers are assigned once at bootup (or at least do not change once assigned). Yes, they do not change once assigned. Take a look at usr.sbin/sensorsd, if you haven't already.
Re: sysctl(3) and iteration over HW_SENSORS
Constantine A. Murenin wrote: > You can't get them all at once with one sysctl(3) call, as the memory > they occupy is not allocated continuously -- a linked list is used, > and each driver does sensor allocation on its own, and it's not a > sysctl(3) job to merge this linked list together into an array. > Ah, thanks. From that perspective I can see that the use of the term "array" in the sysctl(3) man page under HW_SENSORS doesn't necessarily mean a literal array being written in the *oldp buffer; I hope the confusion was at least understandable, though. According to the source, `/sbin/sysctl hw.sensors` calls its own main parsing routine 256 times to check each of the 256 possible sensors and allocates its own list from the results. Eek. Since I'm just writing a voltage monitor I suppose I could have it do that once on init and then just monitor the specific sensors it finds relevant, assuming I can convince myself that the numbers are assigned once at bootup (or at least do not change once assigned). Thanks again, Weldon
Re: sysctl(3) and iteration over HW_SENSORS
On 11/07/06, Weldon Goree <[EMAIL PROTECTED]> wrote: the buffer must hold? And how do I get all of them at once like (I think) sysctl(3) says I can? You can't get them all at once with one sysctl(3) call, as the memory they occupy is not allocated continuously -- a linked list is used, and each driver does sensor allocation on its own, and it's not a sysctl(3) job to merge this linked list together into an array.
Re: sysctl(3) and iteration over HW_SENSORS
On Mon, 10 Jul 2006, Weldon Goree wrote:
> sysctl(3) says that sysctl({CTL_HW, HW_SENSORS}, 2, NULL, &some_size_t,
> NULL, 0) should give me the size of the array of struct sensor's that
> sysctl({CTL_HW, HW_SENSORS}, 2, &some_buffer, &length_thereof, NULL, 0)
> will put into &some_buffer.
>
> Or so I thought. In fact, it returns -1 and sets errno to ENOTDIR, which
> it then diagnoses as my specifying a non-terminal MIB. sysctl(1) shows
> me that I have 7 hw.sensors, but obviously that is a variable among
> systems; how am I supposed to find the number of struct sensor's that
> the buffer must hold? And how do I get all of them at once like (I
> think) sysctl(3) says I can? Should I just run sysctl({CTL_HW,
> HW_SENSORS, i}, 3 ...) for increasing values of i until it returns -1?
I'm afraid it's seven worse. sensors are not contiguous. On my amd64,
I see:
hw.sensors.0=it0, Fan1, 3183 RPM
hw.sensors.2=it0, Fan3, 5273 RPM
hw.sensors.3=it0, VCORE_A, 1.36 V DC
...
Take a look how sbin/sysctl does it's think. AFAIK, there's no other
way. This is something that really needs improvement.
-Otto
