Re: splitting sysctl

[Hiten Pandya <hmp@xxxxxxxxxxxxx>]

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
> :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

	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.

	Regards,

--
Hiten Pandya
hmp@xxxxxxxxxxxxx