DragonFly kernel List (threaded) for 2003-10
Re: splitting sysctl
: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
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!