Messages in this thread | | | Date | Wed, 14 May 2008 09:36:10 +0900 | From | KaiGai Kohei <> | Subject | Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) |
| |
Chris, what is the status of the patch?
KaiGai Kohei wrote: > Chris Wright wrote: >> * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote: >>> [PATCH 2/3] exporting capability name/code pairs >>> >>> This patch enables to export code/name pairs of capabilities the running >>> kernel supported. >>> >>> A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN >>> at 2.6.25. However, we have no interface to disclose what capabilities >>> are supported on the running kernel. Thus, we have to maintain libcap >>> version in appropriate one synchronously. >>> >>> This patch enables libcap to collect the list of capabilities at run >>> time, >>> and provide them for users. It helps to improve portability of library. >>> >>> It exports these information as regular files under >>> /sys/kernel/capability. >>> The numeric node exports its name, the symbolic node exports its code. >> >> I do not understand why this is necessary. The capability bits are an >> ABI >> that shouldn't change in a non-backward compat way (i.e. only additions). >> >> We typically don't export strings <-> number conversions for constants. >> I know you've explained this a few times before, but it still seems to me >> like a userspace only problem. What can userspace do with a capability >> it does not know about? > > When we run a userspace utility on the latest kernel, it has to be compiled > with kernel-headers which have same capability set at least. > If installed userspace utility does not support newly added capabilities, > it requires users to rebuild their utilities when they update the kernel. > > Typically, kernel developer faces this kind of version mismatching. > When they boots their kernel with new capabilities, it also requires to > rebuild libcap. Then, they have to revert it, when they boots with normal > kernel. > > If libcap can know what capabilities are supported on the running kernel > automatically, it does not need users to rebuild libcap concurrently. > > Thanks,
-- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
| |