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>