svn commit: r214510 - in head: include lib/libc/gen sys/kern
gcooper at FreeBSD.org
Sat Oct 30 00:52:47 UTC 2010
On Fri, Oct 29, 2010 at 3:21 PM, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
> On Fri, Oct 29, 2010 at 01:31:10PM +0000, David Xu wrote:
>> Author: davidxu
>> Date: Fri Oct 29 13:31:10 2010
>> New Revision: 214510
>> URL: http://svn.freebsd.org/changeset/base/214510
>> Add sysctl kern.sched.cpusetsize to export the size of kernel cpuset,
>> also add sysconf() key _SC_CPUSET_SIZE to get sysctl value.
>> Submitted by: gcooper
>> +#ifdef _SC_CPUSET_SIZE
>> + case _SC_CPUSET_SIZE:
>> + len = sizeof(lvalue);
>> + if (sysctlbyname("kern.sched.cpusetsize", &lvalue, &len, NULL,
>> + 0) == -1)
>> + return (-1);
>> + return (lvalue);
>> +static size_t _kern_cpuset_size = sizeof(cpuset_t);
>> + * Return the size of cpuset_t at the kernel level
>> + *
>> + * XXX (gcooper): replace ULONG with SIZE once CTLTYPE_SIZE is implemented.
>> + */
>> +SYSCTL_ULONG(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD,
>> + &_kern_cpuset_size, 0, "Kernel-level cpuset_t struct size");
> Because it is used via sysconf(3), I don't think it should be converted
> to CTLTYPE_SIZE at all. I even think it would be safer to make
> _kern_cpuset_size a long (sysconf's lvalue is long) and (just for
> consistency) use SYSCTL_LONG().
size_t is synonymous with long though (minus the fact that size_t is
unsigned and long is signed).
cperciva came up with same question, and the thing that I noted is
that SYSCTL_SIZE, etc was going to be implemented in the not so
distant future (I have the tunables done; I was going to finish off
the sysctl(9) analogs all in one shot to avoid having to bump
__FreeBSD_version__ twice, but was waiting for all of the parts to
come in for my router box so I could get my test box online, but
that's a sidenote :)..).
des preferred the semantics of SIZE and POINTER, etc in the tunables
because of the concept it implies over a long (even though they're
basically synonyms at one level or another). The comment was there as
a reminder to me to get the work done quicker :).
> Also note, that on i386 long is 32bit and on amd64 long is 64bit, so
> 32bit process running on 64bit system won't be able to read this sysctl.
> Or do we detect 32bit processes on 64bit systems and convert such types
> in the kernel?
There are two things I've been thinking about with this work though:
1. sysctls truncate output over 64-bit with certain datatypes, like
LONGs (SIZE, POINTER, etc would apply as well in the above example). I
thought this was an undesirable loss of precision, but I'd need to
talk to someone else about this.
2. It might be convenient if there was a lookup table for certain
types like FDSET (like Robert brought up) where userland and kernel
space types can vary like with cpuset_t. Just an idea to ponder over
in my free time that I might bring up to more senior folks for more
thorough consideration because it would be a cleaner interface to
determining datatypes widths like this.
Thanks for the comments though :)!
More information about the svn-src-all