sysctl variable question
mdf at FreeBSD.org
mdf at FreeBSD.org
Mon Dec 19 01:15:57 UTC 2011
2011/12/18 Fernando Apesteguía <fernando.apesteguia at gmail.com>:
> El 18/12/2011 22:12, "Julian Elischer" <julian at freebsd.org> escribió:
>> On 12/18/11 12:18 PM, Fernando Apesteguía wrote:
>>> Hi all,
>>> I'm writing a small module just for fun. I would like to have two
>>> - "pid" of type unsigned int and RW so the user can set a pid
>>> - "process_name" as a string RD that will display the process name
>>> associated to that pid (or a message if the pid doesn't exist anymore)
>> this is dangerous as there are some places in the kernel where processes
>> are referenced by pid, so changing it may break kernel assumptions.
> Sorry, i think i didn't explain it clearly. The "pid" variable is static in
> my module and it is used just to tell the module which information it
> should show in the other variable.
Many sysctl handlers look for a req->newptr and leave early if it's
NULL. If it's non-NULL then you can use SYSCTL_IN to fetch the data.
Note that a caller of sysctl(3) API can specify both old pointer and
new pointer, which is why most handlers always do a SYSCTL_OUT on the
>>> My problem is with the handler functions. For "process_name", as it is
>>> read only, I wrote a simple handler that works fine. However, I want
>>> to write another one for "pid" so I can sanitize the input (avoiding
>>> pids< 0 and so). As I understand, the handler I specify with
>>> SYSCTL_OID will be called for both reads and writes. But, how can I
>>> tell what kind of operation is it, so I know if I have to use
>>> SYSCTL_OUT or SYSCTL_IN? I tried to have a look at sysctl_handle_int
>>> but I don't fully understand what is going on with the arg1 parameter.
>>> What is it for?
>>> Thanks in advance.
>>> freebsd-hackers at freebsd.org mailing list
>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-hackers