lkml.org 
[lkml]   [2008]   [Apr]   [23]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 22 Apr 2008 22:37:26 -0700
FromChris Wright <>
SubjectRe: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)
* 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?

thanks,
-chris


\
 
 \ /
  Last update: 2008-04-23 07:47    [W:1.349 / U:0.150 seconds]
©2003-2008 Jasper Spaans