From owner-soc-status@FreeBSD.ORG Fri Jun 18 22:28:45 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 19197106566B; Fri, 18 Jun 2010 22:28:45 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 97E148FC16; Fri, 18 Jun 2010 22:28:44 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 4C24814DBC34; Sat, 19 Jun 2010 00:28:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8K83xjgIsCNL; Sat, 19 Jun 2010 00:28:40 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id AC86714DBABB; Sat, 19 Jun 2010 00:28:40 +0200 (CEST) Message-ID: <4C1BF313.9040903@FreeBSD.org> Date: Sat, 19 Jun 2010 00:28:35 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: pluknet References: <4C1BCB96.4040608@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 18 Jun 2010 22:28:45 -0000 El 2010. 06. 18. 23:43, pluknet escribió: > On 18 June 2010 23:40, Gabor Kovesdan 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