* Andrew G. Morgan (morgan@kernel.org) wrote:
quoted text
> Chris Wright wrote:
> | I'm sure you're painfully aware, but this will need some change
> | to libcap as well (to let it handle 64bit caps again).
>
> Not really.
>
> libcap2 (the one with 64-bit capability support) continues to work fine
> (it ships with its own copy of a compatible linux/capability.h, and when
> I update that, I'll make the corresponding change) but the effect should
> be transparent to its users:

Doh, I missed the leading portion of the pathname (cscope -p3 didn't
show anything more than include/sys/capability.h), thanks.

quoted text
> | That's what I meant earlier by "And use another mechanism to
> | signal the availability of 64bit caps."
>
> There is and has always been a method:
>
> ~   head.version = 0;
> ~   getcap(&head, NULL);
> ~   switch (head.version) {
> ~   case _LINUX_...:
> ~      ...
> ~      break;
> ~   case _,,,,:
> ~      etc...
> ~      break;
> ~   default:
> ~      abort("no idea what to do");
> ~   }

Hmm, it would be kind of nice to have a formalized way get the size,
perhaps it would help with KaiGai's request for caps printed out.
Something that tells us either the number of u32s, or the max bit
supported?

quoted text
> | All looks good.  I think we need to issue some warnings, because
> | at least Fedora 9 and openSUSE 11 are/will be 2.6.25 based.
>
> Do any of the above answers help? (FWIW I attached the patch to the
> redhat bug.)

Yes, thanks.  But I still think we need to print a warning (unfortunately
we can't distinguish libcap from non-libcap app), because apps that
aren't using libcap should really be updated (either pull new update
from vendor or recompiled by end user).

thanks,
-chris
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/