Date: Sat, 19 Jun 2010 12:22:59 +0400 From: pluknet <pluknet@gmail.com> To: Gabor Kovesdan <gabor@freebsd.org> Cc: soc-status@freebsd.org Subject: Re: Collective resource limits status report #3 Message-ID: <AANLkTinxW4GPJCJxGUgiDTxEl0dQyoiCLgM-lm7ohlaF@mail.gmail.com> In-Reply-To: <4C1BF313.9040903@FreeBSD.org> References: <4C1BCB96.4040608@FreeBSD.org> <AANLkTikwUYWCIvlDQ60L4L8gMcEeDFIV6850csEwuH8E@mail.gmail.com> <4C1BF313.9040903@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 June 2010 02:28, Gabor Kovesdan <gabor@freebsd.org> wrote: > El 2010. 06. 18. 23:43, pluknet escribi=F3: >> >> On 18 June 2010 23:40, Gabor Kovesdan<gabor@freebsd.org> =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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinxW4GPJCJxGUgiDTxEl0dQyoiCLgM-lm7ohlaF>