YAMAMOTO Takashi wrote:

> - "metahook" sounds like a confusing name.  (sorry, no alternative suggestion.)

This is the name until there's an alternative.

> - it's better to make metahhook-id an opaque type rather than a plain int.

I'll introduce metahook_t.

> - how does it handle fileid recycles?

It doesn't and it won't. The code that makes use of metahook(9) needs
to do this. Look at Veriexec.

> - "inode" is a filesystem dependent term.

Is there an alternative? if not, this is what it'll use and file-systems
that can't offer an inode entity are simply not supported.

> - using dev_t here seems weird to me.  isn't it better to use
>   a pointer to struct mount?

Aren't they really the same? what is the benefit?

> - why ignore hashmask returned by hashinit?

Leftovers. Fixed.

> - what's a locking strategy?  "leave it callers"?

Yes.

> - metahook_inode_delete and metahook_table_delete seem to use
>   "mhe" after freeing.

Oops, fixed.

> - i don't think M_TEMP is appropriate.

It isn't. But that's easy to change by introducing a new malloc
type.

> - 0 and 1 should be METAHOOK_CLEANUP_* ?

Yes.

-e.

-- 
Elad Efrat