Subject: Re: kern/35253
To: None <,,>
From: Elad Efrat <>
List: netbsd-bugs
Date: 12/26/2006 10:10:04
The following reply was made to PR kern/35253; it has been noted by GNATS.

From: Elad Efrat <>
To: YAMAMOTO Takashi <>
Subject: Re: kern/35253
Date: Tue, 26 Dec 2006 12:08:52 +0200

 YAMAMOTO Takashi wrote:
 >> YAMAMOTO Takashi wrote:
 >>>> we can do something like this:
 >>>> 	fileassoc_table_size(struct mount *mp);
 >>>> 		return number of slots table for 'mp' was optimized for.
 >>>> 	fileassoc_table_optimize(struct mount *mp, size_t nentries);
 >>>> 		optimize the hash-table for 'mp' for 'nentries' slots.
 >>>> notes:
 >>>>   - there should be locking implications to fileassoc_table_optimize(),
 >>>>   - the wording avoids exposing internal implementation details of
 >>>>     fileassoc(9).
 >>> it's better to just remove fileassoc_table_add from API
 >>> and just do them internally, IMO.
 >> you mean, when a file entry is added, create the table if it's not
 >> already there?
 > yes, and resize hash appropriately according to the number of entries.
 on each addition? :)
 maybe we can add some "barriers", to intelligently resize the table...