Re: splitting sysctl

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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
:tollerable?
:
:-- 
:   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!

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>