[PATCH 22/58] Audit: Change audit_sig_sid to audit_sig_lsm

[Casey Schaufler]

On 6/6/2019 1:53 PM, Kees Cook wrote:
> On Thu, Jun 06, 2019 at 12:17:42PM -0700, Casey Schaufler wrote:
>> On 6/6/2019 11:41 AM, Kees Cook wrote:
>>> On Mon, Jun 03, 2019 at 03:23:07PM -0700, Casey Schaufler wrote:
>>>> Maybe lsm_export_is_interesting()?
>>>> I'd love to discover there's a convention I could adhere to.
>>> I'd agree "lsm_data" seems meaningless. lsm_export does seem a better
>>> name, though it has the "export is also a verb" issue. Would "lsm_context"
>>> or "lsm_ctx"?
>>> be better?
>>>
>>> then we get lsm_ctx_is_interesting() and lsm_ctx_to_secid() ?
>> Fiddling around with this led me to think "struct lsmdata"
>> would work, although maybe "struct lsmblob", in keeping with
>> the notion it is opaque. Leaving out the "_" helps with the
>> verb issue, I think. I think ctx or context is right out, as
>> secctx is the string representation, and it would really confuse
>> things.
> Ah yeah, good point on "context". Does "blob" conflict with the existing
> "blob" stuff?

I don't think so. Some people might think it a bit too cute,
but I kind of like it.

>  If it's always going to be u32 data, do we want it to be
> lsm_u32 ?

At some point I would love to have the Smack data be a
struct smack_known pointer, but that's a future thing.

>  Or, since it's a multiplexor, lsmmux ?

I'd rather describe what's in it than how it's used.