Collective resource limits status report #3

[pluknet]

On 19 June 2010 02:28, Gabor Kovesdan <gabor at freebsd.org> wrote:
> El 2010. 06. 18. 23:43, pluknet escribió:
>>
>> On 18 June 2010 23:40, Gabor Kovesdan<gabor at 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.

Ah, you're right. Didn't think about that.

-- 
wbr,
pluknet