lkml.org 
[lkml]   [2007]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: LSM conversion to static interface [revert patch]
    * Arjan van de Ven (arjan@infradead.org) wrote:
    > On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
    > James Morris <jmorris@namei.org> wrote:
    >
    > > On Sat, 20 Oct 2007, Jan Engelhardt wrote:
    > >
    > > > >I'd like to note that I asked people who were actually affected,
    > > > >and had examples of their real-world use to step forward and
    > > > >explain their use, and that I explicitly mentioned that this is
    > > > >something we can easily re-visit.
    > > > >
    > > >
    > > > I do have a pseudo LSM called "multiadm" at
    > > > http://freshmeat.net/p/multiadm/ , quoting:
    > > >
    > >
    > > Based on Linus' criteria, this appears to be a case for reverting the
    > > static LSM patch.
    >
    > I don't want to argue for or against the actual revert; however if Linus/James/Chris
    > decide to do a revert, I've made a patch to do that below

    Thanks Arjan. I did not actually oppose making it non-modular, and
    thought there was sufficient time for people to complain meaningfully
    on that change. I also think there's not a lot of value in the modular
    interface, but it's very difficult to have rational discussions in this
    area.

    > (doing a full git revert is tricky since it gets mixed up with various other cleanup
    > patches; even inside the original patch. I've done the relevant pieces by hand via a
    > selective patch -R and compile-tested it). In addition I've made the modularity a
    > Kconfig option, since it's clearly something that is contested and thus is justified
    > as a user compile time choice; people who don't want this (out of paranoia or otherwise)
    > can now decide to disable, while others who want to experiment or use out of tree
    > LSM modules, can select the KConfig option.
    >
    > If it turns out that the above module becomes unmaintained and no longer usable, and no
    > other useful cases show up, we can always garbage collect this code in the future; it's
    > now low-overhead anyway for those who care, due to the KConfig option.

    Yes, and I think we can still improve performance although I can't see
    anyway to help out the modular case, so I guess it will have to incur
    the hit that's always been there. I think your Kconfig option is a
    decent compromise.

    thanks,
    -chris
    -
    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: 2007-10-23 07:19    [W:4.503 / U:1.252 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site