[trimming the Cc: list] > * Jack O'Quin <[EMAIL PROTECTED]> wrote: >> Remember when I asked how you handle changes to sizeof(struct rusage)? >> That was a serious question. I hope there's a solution. [...]
Ingo Molnar <[EMAIL PROTECTED]> writes: > what does any of what we've talking about have to do with struct rusage? Your previous message implied that "userspace" programmers don't understand binary compatibility... > you might ask yourself, 'why is this so, and why cannot the Linux guys > apply pretty much any hack as e.g. userspace code might' I was just demonstating that I do. > " > Does getrusage() return anything for this? How can a field be added > > to the rusage struct without breaking binary compatibility? Can we > > assume that no programs ever use sizeof(struct rusage)? > > rlimits are easily extended and there are no binary compatibility > worries. The kernel doesnt export the maximum towards userspace. > getrusage() will return the value on new kernels and will return > -EINVAL on old kernels, so new userspace can deal with this > accordingly. " > > (and here i meant getrlimit(), not getrusage() - getrusage() is not > affected by the patch at all.) Well, that was source of my question. I had asked about rusage. You said it did return a new value, but that this was not a problem. That made no sense to me. Thank you for clearing it up. Certainly getrlimit() works OK. I understood that already. -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
