>from cache).  From what I understand an associative hash table would
>mean a number of smaller lists that can be searched more quickly which

Yep.  You might want to check out hsearch(3) which is present in 1.4
(the solaris version quotes the algorthim used from Knuth :-) 

>the result stored in the DNLC.  The calculation is done by reading the
>entire file and evaluating the md5 signature.  This buggers the joys
>of demand paged binaries but only if there is a cache miss on the
>evaluated signature.  If someone overwrites the binary of a long

Since we are talking clued bad guys... open(2) detects text busy but
is that infallible?  Is there no way that they can update pages of a
running binary?  If the answer to either is not provably "yes", then
in the presence of demand paging, you'd really need to compute 
(and re-compute) the hash of each page as (and when ever) you paged it in, 
otherwise how do you know that your cached hash is still valid?

If indeed you do need to cache individual hashes for each page (or pagable 
unit) of every binary, the overhead would likely be very significant.

--sjg