Subject: Re: Reading sysctl values in the kernel
To: Alan Ritter <rittera@cc.wwu.edu>
From: Andrew Brown <atatat@atatdot.net>
List: tech-kern
Date: 07/24/2005 20:46:56
On Sun, Jul 24, 2005 at 05:17:44PM -0700, Alan Ritter wrote:
>Hi, thanks for your response :-)
sure. :)
>> (1) sc->ndis_sysctl_mib is the top-level mib number?
>Yes, I enter it in, and get the mib number like so:
> /* Create the sysctl tree. */
> sysctl_createv(&sc->sysctllog, 0, NULL, &ndis_node,
> CTLFLAG_READWRITE, CTLTYPE_NODE,
> sc->ndis_dev->dv_xname, NULL, NULL, 0,
> NULL, 0, CTL_CREATE, CTL_EOL);
>
> /* Store the number of the ndis mib */
> sc->ndis_sysctl_mib = ndis_node->sysctl_num;
ok, so it's at the top-level. i wasn't sure.
>> (2) do you have more than one node under sc->ndis_sysctl_mib?
>>
>Yes, I enter a whole bunch of nodes from the Windows .inf file (these are
>supposed to be registry keys) like this (inside a loop)
>
> sysctl_createv(&sc->sysctllog, 0, NULL, NULL,
> CTLFLAG_READWRITE|CTLFLAG_OWNDESC, CTLTYPE_STRING,
> vals->nc_cfgkey, vals->nc_cfgdesc, NULL,
> 0, vals->nc_val, strlen(vals->nc_val),
> ndis_node->sysctl_num, CTL_CREATE, CTL_EOL);
that works. okay, so you have "n" children and not "1".
i note, however, that you're telling the sysctl subsystem to copy (and
"own") the description, but not the data actually being instrumented.
since these are writeable values, i presume you're taking care that
the space for the data is not going to be reused accidentally? also,
the space alloted for each "value" is only as large as the space you
indicate here (via the strlen() call).
>> (3) when you get back the response from sysctl_dispatch(), you'll have
>> an array of nodes which you'll have to look through to find the one
>> you want.
>
>Actuially I changed the way I am looking for the keys (when I later need
>to look them up based on their name. I'm using sysctl_locate() to find
>the root of the tree that I stash all these nodes in, and from there I
>just itterate through the child field in the "struct sysctlnode" like so:
>
> mib[0] = sc->ndis_sysctl_mib;
>
> sysctl_lock(curlwp, NULL, 0);
> error = sysctl_locate(curlwp, &mib[0], 1, &pnode, NULL);
>
> numcld = pnode->sysctl_csize;
> ndiscld = pnode->sysctl_child;
>
> /* find the node whose name is keystr */
> for(i=0; i < numcld; i++) {
> if(strcmp(keystr, ndiscld->sysctl_name) == 0) {
> /* Found it */
> break;
> }
> ndiscld++;
> }
> sysctl_unlock(curlwp);
>
>This seems to work OK, but I'm not sure if it will cause subtle problems,
>as I'm reading directly from the sysctlnode structure.
it's a little outside of the normal usage, but as long as you acquire
(and release, of course) the lock appropriately, it ought to work just
fine.
>> the problem is probably that you're doing a query but only providing
>> sysctl the space for one node under sc->ndis_sysctl_mib in the
>> response.
>
>Yea, I actuially thoght this might be the problem too, so I tried calling
>sysctl_dispatch with an array of nodes (not the exact number that I
>created though). Maybe I should go back and do it this way if there is a
>problem with directly accessing the node.
no, it shouldn't be a problem, though i should probably add something
to make what you were initially trying to do much easier.
>Anyway thanks again for your help. Let me know if you think I'm still
>doing something wrong. Also in case your interested here's some links to
>my sources on the web:
>-I add the nodes in ndis_create_sysctls() and ndis_add_sysctls() in the
>following file:
>http://cvs.sourceforge.net/viewcvs.py/netbsd-soc/ndis/sys/compat/ndis/kern_ndis.c?rev=1.14&view=log
>-I look them up again in NdisReadConfiguration() (gets called by the
>actual Windows binary driver) in this file:
>http://cvs.sourceforge.net/viewcvs.py/netbsd-soc/ndis/sys/compat/ndis/subr_ndis.c?rev=1.9&view=log
looks good. i'll read these in more depth later. thanks.
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
werdna@squooshy.com * "information is power -- share the wealth."