Collective resource limits status report #3

[pluknet]

On 24 June 2010 11:32, Gabor Kovesdan <gabor at freebsd.org> wrote:
> El 2010. 06. 23. 14:44, pluknet escribió:
>>
>> On 23 June 2010 12:50, Gabor Kovesdan<gabor at freebsd.org>  wrote:
>>
>>>>
>>>> +typedef __uint32_t     __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=0650&db=bks&fname=/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.

-- 
wbr,
pluknet