I agree that RUSAGE_THREAD is fine. (In fact, if you'd pressed me to remember without looking, I would have assumed we put it in already.) However, in the implementation, I would keep it cleaner by moving the identical code from inside the loop under case RUSAGE_SELF into a shared subfunction, rather than duplicating it. In fact, here you go (next posting).
As to getting arbitrary other threads' data, there are several problems there. Adding a syscall is often more trouble than it's worth. Ulrich cited the issues with that as the API. You also didn't handle compat for it correctly. To warrant the code necessary to make this available by whatever API, I think you need to say some more about what it's needed for. Off hand, it seems most in keeping with other things to expose this via a /proc file, i.e. /proc/tgid/task/tid/rusage and (/proc/tgid/rusage for the RUSAGE_SELF behavior on a foreign process). There we already have the infrastructure for dealing with the security issues uniformly with how we control other similar information. Personally I tend to prefer a binary interface, i.e. a virtual file whose contents are struct rusage; for that you still need to do the extra compat work, since a 32-bit process should have the 32-bit struct rusage layout in its /proc files. If you put the numbers into ascii text as some /proc interfaces do, you don't need any special considerations for CONFIG_COMPAT. Thanks, Roland -- 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/
