On Fri, Oct 29, 2010 at 3:21 PM, Pawel Jakub Dawidek <p...@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 >> >> Log: >> 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); >> +#endif > [...] >> +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 :)! -Garrett _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"