Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jun 2010 00:28:35 +0200
From:      Gabor Kovesdan <gabor@FreeBSD.org>
To:        pluknet <pluknet@gmail.com>
Cc:        soc-status@freebsd.org
Subject:   Re: Collective resource limits status report #3
Message-ID:  <4C1BF313.9040903@FreeBSD.org>
In-Reply-To: <AANLkTikwUYWCIvlDQ60L4L8gMcEeDFIV6850csEwuH8E@mail.gmail.com>
References:  <4C1BCB96.4040608@FreeBSD.org> <AANLkTikwUYWCIvlDQ60L4L8gMcEeDFIV6850csEwuH8E@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
El 2010. 06. 18. 23:43, pluknet escribió:
> On 18 June 2010 23:40, Gabor Kovesdan<gabor@freebsd.org>  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: http://kovesdan.org/patches/jobs_current.diff
>>
>>      
> 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 
implementation.
> 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@FreeBSD.org .:|:. gabor@kovesdan.org
WEB:   http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C1BF313.9040903>