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.
