Subject: Re: Replacing the sysctl() interface.
To: Darren Reed <firstname.lastname@example.org>
From: Eduardo Horvath <email@example.com>
Date: 06/06/2000 10:28:25
On Wed, 7 Jun 2000, Darren Reed wrote:
> 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 ?
If you have a bunch of SPARCs, some of them are V8 and some V9, you would
want to be able to share the binaries, wouldn't you? You might even want
them all to NFS mount the same /usr.
> Secondly, is this something which sysctl(3) can be expected to perform ?
> This would still pose problems for staticly linked binaries.
Yes. Syscall emulation has traditionally been done inside the kernel.
> 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.
Yes, but the latter method still needs knowledge of the type of each
field. Better to have the emulation provide a set of converter
routines. That way you can handle arbitrary emulations.