lkml.org 
[lkml]   [2005]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/5] Rework stubs in security.h
On Fri, Aug 26, 2005 at 10:59:52AM -0700, Chris Wright wrote:
> * Tony Jones (tonyj@suse.de) wrote:
> > The discussion about composing with commoncap made me think about whether
> > this is the best way to do this. It seems that we're heading towards a
> > requirement that every module internally compose with commoncap.
>
> Not a requirement, it's a choice ATM.

Can you think of a case where the choice (on the part of the module author)
to not do so makes any sense?

> Heh, this was next on my list. I just wanted to separate the changes to
> one at a time so we can easily measure the impact. This becomes another
> policy shift.

I understand the advantages of clearly measuring the impact of each change
independantly but with SELinux having to change how they use their secondaries
at the same time, I'm not sure there is a lot of difference between the
two phases.

> > If every module is already internally composing, there shouldn't be a
> > performance cost for the additional branch inside the #ifdef.
>
> This needs measurement to verify.

Agreed. So does the current proposal :-)

Tony
-
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/

\
 
 \ /
  Last update: 2005-08-26 20:10    [W:1.763 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site