On 6/6/2019 1:53 PM, Kees Cook wrote:

On Thu, Jun 06, 2019 at 12:17:42PM -0700, Casey Schaufler wrote:

quoted

On 6/6/2019 11:41 AM, Kees Cook wrote:

quoted

On Mon, Jun 03, 2019 at 03:23:07PM -0700, Casey Schaufler wrote:

quoted

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.