Collective resource limits status report #3

Gabor Kovesdan gabor at
Fri Jun 18 22:28:45 UTC 2010

El 2010. 06. 18. 23:43, pluknet escribió:
> On 18 June 2010 23:40, Gabor Kovesdan<gabor at>  wrote:
>> Hello,
>> since the last report, I made my code compilable, although it doesn't
>> completely work yet. Now I'm working on finding what is going wrong. While I
>> spent time with buildworld/buildkernel compilations, I wrote manual pages
>> for the syscalls implemented and also extended the test utility a bit. For
>> next week, my goal is to make these totally work and start to work on actual
>> resource limits. First step to accomplish this is adding containers for
>> resource usage accounting. Edward's hrl code will be a big help for this and
>> I'll consider his work-in-progress project when doing this task, trying to
>> come up with a more general solution that is also useful for his work and
>> later improvements on resource limits.
>> Bad news is that I've had some problems with Perforce. I used it many many
>> times, I know how it works but seems that recent client utility is either
>> buggy or developers broke compatibility and I experienced a very different
>> behaviour this time. I just sent a mail to developers@ about this, this is
>> something that we should look at. This made the history in my p4 repo a
>> total mess but supposedly code is there so you can check out. For easier
>> review, I'm also providing a patch for head with all the code I wrote. I
>> know this is not much but it took time to get into the kernel internals and
>> it also took time to compile the code and eliminating compile errors
>> one-by-one. Hopefully, as I'm getting into it, I'll progress more and more
>> quickly. The patch is here:
> First, thank you for doing this! Please, let me comment a little
> (that's rather a thinking aloud, don't take it too seriously).
> As I see, you decided to follow a bug-for-bug compatibility way and chose
> to bring in a new error type ENOPKG. That's sort of surprise since, as I know,
> ENOPKG is an IRIX specific error code meaning that a particular IRIX
> installation
> doesn't come with job limit feature installed, and that doesn't fit nicely in to
> the FreeBSD world. Does it make sense to define it at all?
> Also, I see no purpose to use it anywhere.
Yes, it's not used but it is important to provide real API 
compatibility. Imagine a source that has a

if (errno == ENOPKG) { ...}

line after calling some of the calls. We want it to compile with our 
> Why don't define __jid_t as it's done for uid_t, gid_t, pid_t?
> Why do jid_t to be 64-bit capable? IMHO it should follow uid_t capacity, as far
> as jobs are created per uid (and that's noted in makenewjob(2)).
Yeah, the reason was to provide more capacity but your point makes 
sense, I'll decrese it to 32-bit.
> I would make something like following (not important parts missed
> intentionally).
> [job limits are like struct plimit (both are based on BSD struct
> rlimit in my variant),
> so I decided to include jid_t limits (and name it struct ulimit here)
> into struct uidinfo
> since that's something similar to stuct plimit, but unlike plimit
> which is designed
> to be per process, an ulimit is per uid; hence its name: "user limit".
> Though I don't
> like that now there are excessively two new fields in struct uidinfo.]
Thanks, I'll thoroughly review your patch. I see it also has better 
style than mine one, I haven't yet learned totally all the conventions 
inside the kernel.

Gabor Kovesdan
FreeBSD Volunteer

EMAIL: gabor at .:|:. gabor at
WEB: .:|:.

More information about the soc-status mailing list