From owner-svn-src-head@FreeBSD.ORG Sat Oct 30 00:52:47 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E900F1065674; Sat, 30 Oct 2010 00:52:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 51CFE8FC0A; Sat, 30 Oct 2010 00:52:46 +0000 (UTC) Received: by ywh2 with SMTP id 2so1874534ywh.13 for ; Fri, 29 Oct 2010 17:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Hm8BTEjJU+XiOFNBJ+lfI8D4n7IvJKxEUyuuDgpBNOw=; b=Axc/fxvt6uh9z48d5gJDWe5tHGyRmPGCpb0IlMF1pvYt31x8jtM5gXp1FRYWB+/QLD aEWNQKLR6h/HU04oAEsk3uNWu+7BBULEtcMilzSpYLsrDraBeVj/HV0j/78SmJGLiVxD QAkU+gIB7kgPACHByl5JQtI5B1ar+xpjaSolw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mBraQ6b0dCVWNqZTe/urVIgJdPA7tWXDKP1xLLG2EzdcMML4rWDCVUxu6NdzCQUcct ac4scM5vCnokR5XPGh9unAt1wnxzjqhj7SZygpHnlNubtuGj5wXYRC7gXbx+LqKCXSm9 /55TJMpauBQrDYE1ycZFlv2jqA5+9t0Hyb2cI= MIME-Version: 1.0 Received: by 10.90.4.7 with SMTP id 7mr5147982agd.100.1288399965005; Fri, 29 Oct 2010 17:52:45 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.90.70.19 with HTTP; Fri, 29 Oct 2010 17:52:43 -0700 (PDT) In-Reply-To: <20101029222159.GA2160@garage.freebsd.pl> References: <201010291331.o9TDVAtm027022@svn.freebsd.org> <20101029222159.GA2160@garage.freebsd.pl> Date: Fri, 29 Oct 2010 17:52:43 -0700 X-Google-Sender-Auth: F2Kg-kn54YmT40fyCftuhUKLr2w Message-ID: From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, David Xu Subject: Re: svn commit: r214510 - in head: include lib/libc/gen sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 00:52:47 -0000 On Fri, Oct 29, 2010 at 3:21 PM, Pawel Jakub Dawidek wrot= e: > 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: >> =A0 Add sysctl kern.sched.cpusetsize to export the size of kernel cpuset= , >> =A0 also add sysconf() key _SC_CPUSET_SIZE to get sysctl value. >> >> =A0 Submitted by: gcooper > [...] >> +#ifdef _SC_CPUSET_SIZE >> + =A0 =A0 case _SC_CPUSET_SIZE: >> + =A0 =A0 =A0 =A0 =A0 =A0 len =3D sizeof(lvalue); >> + =A0 =A0 =A0 =A0 =A0 =A0 if (sysctlbyname("kern.sched.cpusetsize", &lva= lue, &len, NULL, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0) =3D=3D -1) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (-1); >> + =A0 =A0 =A0 =A0 =A0 =A0 return (lvalue); >> +#endif > [...] >> +static size_t _kern_cpuset_size =3D sizeof(cpuset_t); > [...] >> +/* >> + * Return the size of cpuset_t at the kernel level >> + * >> + * XXX (gcooper): replace ULONG with SIZE once CTLTYPE_SIZE is implemen= ted. >> + */ >> +SYSCTL_ULONG(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD, >> + =A0 =A0&_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