From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3725 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Proposed roadmap to 1.0 Date: Wed, 24 Jul 2013 13:36:53 -0500 Message-ID: <1374691013.3031.6@driftwood> References: <20130717160204.GF12469@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1374691029 20825 80.91.229.3 (24 Jul 2013 18:37:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jul 2013 18:37:09 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-3729-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 24 20:37:11 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V23vw-0003R0-QE for gllmg-musl@plane.gmane.org; Wed, 24 Jul 2013 20:37:08 +0200 Original-Received: (qmail 16175 invoked by uid 550); 24 Jul 2013 18:37:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16167 invoked from network); 24 Jul 2013 18:37:07 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=cPzrPGdwMD8ZvAilj6/mVoUb/yHJBwga6/prPB7VGj4=; b=O98OLHeM5b4tOe2dcpowYhRqqrDMcxOyoARHtMVyuTo96Q/CZnefbJkrFKV2y656nf 0ZtLdJ42n1wU6sQ1O31BTmBoA3i9uBJTmV+NFIvUbiGLELX78vNSFgTOXcJOtVK360V6 pJlj1viI+neBZseFIL6tEXks6f3dMf0p1hown+1WA6j8bEaC72sCR22R4R3CMBllQxL2 xmHHE0ek1fi4W7/dn8qLAqc0+9dDt5uNzqG+jQtt0Q+Ppi7tED26qFOdgCU13zC/tlIk 1rngBU0YdEcSj+Z3yU8+v2uMcgP/ONIFdoPr48H2kk0QCXKZ068Pf7rmhxDoVZHcC6QC tuKw== X-Received: by 10.182.105.99 with SMTP id gl3mr32098546obb.94.1374691015671; Wed, 24 Jul 2013 11:36:55 -0700 (PDT) In-Reply-To: <20130717160204.GF12469@brightrain.aerifal.cx> (from dalias@aerifal.cx on Wed Jul 17 11:02:05 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQmuiQHrz1a02G2pnYE9lcGQDDB+OSnZ9HTsaDFj9e71dPq/pS7Y6HqAZpMC1kFbKiuXyDdf Xref: news.gmane.org gmane.linux.lib.musl.general:3725 Archived-At: On 07/17/2013 11:02:05 AM, Rich Felker wrote: > > - Affinity/cpuset interfaces. >=20 > Last time I started working on this, I got sick of it before I got > very far. There are just so many tedious macros/inline-functions to > implement. I was also frustrated with having to put so much code in a > public header. For this, I'd really like some help on both: >=20 > - ideas for making it less hideous, and > - actually writing it out. For toybox I ignored the glibc interfaces and just used the raw =20 syscall, manipulating the arguments myself with bit shifts. Let's see... Wow the man 3 CPU_SET macros are crazy. Very first one, CPU_ZERO() does =20 not specify the size of the array. So how does it determine it? It's =20 gotta be getting it from cpu_set_t which is defined in =20 /usr/include/*/bits/sched.h: /* Data structure to describe CPU mask. */ typedef struct { __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS]; } cpu_set_t; So what's _NCPUBITS? /* Size definition for CPU sets. */ # define __CPU_SETSIZE 1024 # define __NCPUBITS (8 * sizeof (__cpu_mask)) /* Type for array elements in 'cpu_set_t'. */ typedef unsigned long int __cpu_mask; So... it's hardwired to 1024 cpus. I don't think there _is_ a way to make this non-ugly. What actually =20 uses this? Rob=