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