From owner-soc-status@FreeBSD.ORG Sat Jun 19 08:23:02 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 1F7E3106564A; Sat, 19 Jun 2010 08:23:02 +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 5A00A8FC0C; Sat, 19 Jun 2010 08:23:00 +0000 (UTC) Received: by wwg30 with SMTP id 30so1911777wwg.13 for ; Sat, 19 Jun 2010 01:22:59 -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=4bgaeXctg4DWxUoPmjdVXNp0ousc9qDS/MF65cmuBW8=; b=yElYXKmdlndZOMye/NhncN568uT1NTlVUJ22oUBL49MoHFOH3JOlRNXYV75DD+IAcc NsIPv7SW+6nNjpLxvng6/QBjARf2Yl1yc/vyoWGIkkdO3bDhtBqKCEnJq79SRn1kulUc TBjG1A1pHmOmsqpnpNkK6saVbVGaGOMfEEVBM= 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=g1ZJA+/vfaUl2x9fYVbdhTvi2A+E9NbiJ40foLMNZRXqCJDEXy33sMpI3EPWaZyDky 2dxNM2Qgqmyf80Tf1OjofETz9lWFwnKyR9tfm1D5b7+rq14x5OfzFjs+xgmLQLy7KtkR 0kwChAKhLi+h7ih84e764dXdP6Ae0P/Tl2EPU= MIME-Version: 1.0 Received: by 10.216.163.79 with SMTP id z57mr1584713wek.17.1276935779490; Sat, 19 Jun 2010 01:22:59 -0700 (PDT) Received: by 10.216.51.78 with HTTP; Sat, 19 Jun 2010 01:22:59 -0700 (PDT) In-Reply-To: <4C1BF313.9040903@FreeBSD.org> References: <4C1BCB96.4040608@FreeBSD.org> <4C1BF313.9040903@FreeBSD.org> Date: Sat, 19 Jun 2010 12:22:59 +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: Sat, 19 Jun 2010 08:23:02 -0000 On 19 June 2010 02:28, Gabor Kovesdan wrote: > El 2010. 06. 18. 23:43, pluknet escribi=F3: >> >> On 18 June 2010 23:40, Gabor Kovesdan =A0wrote: >> >>> >>> 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 pag= es >>> 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 thi= s >>> 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 a= nd >>> 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 eith= er >>> 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 easie= r >>> 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.di= ff >>> >>> >> >> 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 chos= e >> 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 nice= ly >> 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 =3D=3D ENOPKG) { ...} > > line after calling some of the calls. We want it to compile with our > implementation. Ah, you're right. Didn't think about that. --=20 wbr, pluknet