Subject: Re: metahook(9)
To: YAMAMOTO Takashi <email@example.com>
From: Elad Efrat <elad@NetBSD.org>
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?
> - what's a locking strategy? "leave it callers"?
> - metahook_inode_delete and metahook_table_delete seem to use
> "mhe" after freeing.
> - 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_* ?