From owner-soc-status@FreeBSD.ORG Thu Jun 24 08:43:30 2010 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633F71065672; Thu, 24 Jun 2010 08:43:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC458FC13; Thu, 24 Jun 2010 08:43:29 +0000 (UTC) Received: by wwb24 with SMTP id 24so1449644wwb.13 for ; Thu, 24 Jun 2010 01:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kQw2jjWr8CXMU1SVFXgpAfQrbRncnd4D2OVhAtVL6U0=; b=rni6hEYcVaYJZVtafhYT0Jk0uWdVEDnweaSr5a657vBwqsazrzd8QQqFwFCfFg7x1r 33tKIZab4ojTFsK+F7ufs0SyOkwwHwe8v8QBZv55mddotF9G2tvvgjkPorl3rI952w40 mPbbLzOAdFHJBRgJMk7STD3S+sH2rARJkRooE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=COR6IR47GWT8AtLgFLgQc4h6PLnPHKlUcsTqUj0YpgUB5cUY2HSC1jd2U4Ny/QgBL7 gw8E3cXXNJUE9O5s7KTPsoPeYxxk9nIkV7oagM2SwakfUNn0vUaPSip5odEOUxJiH1aJ uoZKN6ASLpFLxFgR/SQ7/W0KGo1+nqbt4hUlA= MIME-Version: 1.0 Received: by 10.216.93.73 with SMTP id k51mr933581wef.97.1277369008368; Thu, 24 Jun 2010 01:43:28 -0700 (PDT) Received: by 10.216.2.73 with HTTP; Thu, 24 Jun 2010 01:43:28 -0700 (PDT) In-Reply-To: <4C230A0B.3080700@FreeBSD.org> References: <4C1BCB96.4040608@FreeBSD.org> <4C21CAF0.2040607@FreeBSD.org> <4C230A0B.3080700@FreeBSD.org> Date: Thu, 24 Jun 2010 12:43:28 +0400 Message-ID: From: pluknet To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: soc-status@freebsd.org Subject: Re: Collective resource limits status report #3 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 08:43:30 -0000 On 24 June 2010 11:32, Gabor Kovesdan wrote: > El 2010. 06. 23. 14:44, pluknet escribi=F3: >> >> On 23 June 2010 12:50, Gabor Kovesdan =A0wrote: >> >>>> >>>> +typedef __uint32_t =A0 =A0 __jid_t; >>>> >>>> >>> >>> This has to be signed because calls may return -1. >>> >> >> It might return jid_t (-1) then as it's done similarly for getpid(2) >> family >> which return pid_t(-1) on error, or similarly for inet_addr(3) which >> returns >> INADDR_NONE (0xffffffff, or -1 for uint32_t, let it be signed) on error. >> > > In the meantime, I've found this: > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=3D0650&db=3Db= ks&fname=3D/SGI_Admin/IA_Resource/apa.html > Now, I changed it back because some applications may expect it to be a > 64-bit variable then, and we are not sure about its relation to uid_t yet= , > so we may provide higher capacity. Hey, it's even more interesting than I could imagine. uid_t, pid_t here are signed types as well, int32_t or long, depending on machine type. That probably explains why jid_t has also a signed type (e.g. might inherit= it). Upper bits in jid_t are reserved for machine ID (has signed int type), used also in IRIX array sessions. That's why jid_t has to be 64-bit capable= . --=20 wbr, pluknet