DragonFly BSD
DragonFly kernel List (threaded) for 2003-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: splitting sysctl

To: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
From: Hiten Pandya <hmp@xxxxxxxxxxxxx>
Date: Sat, 01 Nov 2003 10:22:05 +0000

Matthew Dillon wrote:

:There are a number of COMPAT_43 syscalls that use userland_sysctl().
:I'm trying to figure out if it is possible to do a clean split for
:sysctl() without requiring too many copies.
:Currently, the sysctl code allows the sysctl_req structure to be
:populated with oldfunc() and newfunc() members that move the actual
:data back and fourth. We can choose to move data to and from userland
:by using the userland versions of these functions or we can move data
:within the kernel by using the kernel space versions.
:I'd like to move all of the copyin()/copyout() work out of the sysctl
:internals. To do so without using an excessive amount of copies
:kern_sysctl() could return a pointer to the actual data in the MIB
:tree. Thus, a call to __sysctl() that returns a large string or
:a big chunk of opaque data to userland only has to a single copy.
:The only problem with this approach is that the client function has
:to be careful not to modify which is pointed to. Is this drawback
:-- : David P. Reese, Jr. daver@xxxxxxxxxxxx
: http://www.gomerbud.com/daver/

    I think this is reasonable, especially since you can return a
    const pointer.  However, there will almost certainly be situations
    where the sysctl data is being generated dynamically so you need to
    make a provision for the kernel sysctl functions to be able to
    return malloc()'d memory which the userland interface free()'s after
    it is finished copying it to userland.

e.g. add a flag. Or better yet, encapsulate the request/return in a structure (it doesn't have to be a message though this would
open the door to us using messages in the future if/when we come
up against more complex sysctl situations).

    The sysctl code could really use this sort of cleanup.  It's gotten
    crufty by added hacks over the years!


Another thing that has been running through my mind, is to add some glue functionality to the sysctl code, so that when a flag like (e.g.) SYSCTL_ALSO_TUNABLE is added, it makes the sysctl a loader tunable too. Nothing high priority, but it is a cleanup which we should do sometime.


Hiten Pandya

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]