Subject: Re: metahook(9)
To: YAMAMOTO Takashi <>
From: Elad Efrat <>
List: tech-kern
Date: 06/14/2006 18:10:22
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"?


> - 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

> - 0 and 1 should be METAHOOK_CLEANUP_* ?



Elad Efrat