Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

[KaiGai Kohei]

Chris Wright wrote:
> * KaiGai Kohei (kaigai@xxxxxxxxxxxxx) 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@xxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/