Subject: Re: Replacing the sysctl() interface.
To: Eduardo Horvath <eeh@turbolinux.com>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-kern
Date: 06/07/2000 02:40:48
In some email I received from Eduardo Horvath, sie wrote:
> 
> The `int', strings and `quad's are fairly straight forward.  Structs,
> however, may require conversion.  For example `kern.boottime' returns a
> `struct timeval' which is:
> 
> struct timeval {
> 	long	tv_sec;		/* seconds */
> 	long	tv_usec;	/* and microseconds */
> };
> 
> And `long' is 32-bits in ILP32 but 64-bits in LP64.  This structure needs
> to be converted properly before being copied out.  The current interface
> just does:
> 
> #define SYSCTL_SCALAR_CORE_LEN(oldp, oldlenp, valp, len) 		\
> 	if (oldlenp) {							\
> 		if (!oldp)						\
> 			*oldlenp = len;					\
> 		else {							\
> 			if (*oldlenp < len)				\
> 				return(ENOMEM);				\
> 			*oldlenp = len;					\
> 			error = copyout((caddr_t)valp, oldp, len);	\
> 		}							\
> 	}
> 
> 
> > To me, it is a problem for the in-kernel sysctl code.  There, the code
> > knows the size of the userland object into which the value is being
> > stored, as well as the size of the object in the kernel to be copied back.
> > >From that information, it should be relatively easy to determine if it
> > is a 64bit object into a 32bit container.
> 
> True, but the code does not know the layout of the kernel or userland
> object being copied out so it cannot make the appropriate
> conversions.  Appropriate converters need to be called for each different
> object.  In the default case (kernel and userland are the same) these
> converters simply do the copyin()/copyout().  Otherwise marshalling must
> be done.

Hmmm.

How much of a problem is this, really, for us ?  Do we want to ship 32bit
binaries to run on 64bit kernels or do we want to enable 3rd parties to
build 32bit apps which run on a 64bit system ?

Secondly, is this something which sysctl(3) can be expected to perform ?
This would still pose problems for staticly linked binaries.

If we go the SNMP approach, then each of the members in a struct is made
available, individually and we don't have the problem of opaque structs.
I don't think this is at all efficient for structures such as proc/file.
It is also more overhead in terms of setting up data structures in terms
of sysctl "things" to deal with.

Another slow method, which would preserve returning structs, is to write
the sysctl copy routines to copy structs member by member, handling the
coversion of any pointers/longs as required on a case by case basis.

Darren