[openbeos] Re: resource.h, rlimit, rusage

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Tue, 16 Sep 2003 13:09:02 +0200 CEST

Hi Andrew,

"Andrew Bachmann" <shatty@xxxxxxxxxxxxx> wrote:
> In my somewhat recent header wanderings I noticed that we have 
> a resource.h in private/kernel.  

I think this mail would be perfectly suitable for the kernel mailing 
list :-)
If you are a member of it, please reply to that list.

> This header is entirely compatible and suitable for usage as the 
> posix sys/resource.h header.  No changes to the header need to 
> be made, although the header should have some additions to be 
> R5 & posix compatible.  These are the additions:
> [...]
> It's my understanding that getrusage is public R5 and so we support 
> it.  However, I realize that this support will likely require kernel 
> support, 
> and a new syscall. (?)  None of our current source exercises rusage
> functionality. (unsurprisingly)

Exactly. At the time we forked the NewOS kernel, someone (I don't want 
to defame anyone, of course :-)) put all headers in the private/kernel/
 directory.
Of course, most of them just don't belong there.
It's my habit to let them there until I looked over it, making a BeOS 
compatible replacement, and putting that into the public header tree.
That's why...

> I have been building with a modified and relocated resource.h for 
> some time.  Here's my proposal:
> 
> 1. make the above additions to a copy of our resource.h
> 2. check it in at current/headers/posix/sys/resource.h
> 3. remove the existing current/headers/private/kernel/resource.h

... this proposal is almost exactly what I would have done. If the 
existing resource header is license compatible, just continue to do so, 
if not, please recreate it entirely.

> Are there any comments or objections?  BTW, the free bsd rusage 
> has a lot more fields than the R5 rusage struct does.  The R5 rusage 
> struct contains only those mandated by the posix spec, and 
> those are the only ones I was planning to add. (ru_utime, ru_stime)

I think it would be nice to have some more fields than just those two.
And it would even be possible to do that without losing binary 
compatibility:

struct rusage {
        ... [many fields]
};
#define getrusage(who, rusage) _getrusage(who, rusage, sizeof(struct 
rusage));
extern int getrusage(int who, struct rusage *r);

While our posix/sys/resource.c would contain:

#undef getrusage
int getrusage(int who, struct rusage *r);

int
getrusage(int who, struct rusage *r)
{
        return _getrusage(who, r, 2 * sizeof(struct timeval));
}

That would be the same way as Be went with several get_X_info() calls 
in the kernel.

Adios...
   Axel.


Other related posts: