On 03.12.20 16:08, Jan Beulich wrote: > On 01.12.2020 09:21, Juergen Gross wrote: >> Add a HYPFS_VARDIR_INIT() macro for initializing such a directory >> statically, taking a struct hypfs_funcs pointer as parameter additional >> to those of HYPFS_DIR_INIT(). >> >> Modify HYPFS_VARSIZE_INIT() to take the function vector pointer as an >> additional parameter as this will be needed for dynamical entries. >> >> For being able to let the generic hypfs coding continue to work on >> normal struct hypfs_entry entities even for dynamical nodes add some >> infrastructure for allocating a working area for the current hypfs >> request in order to store needed information for traversing the tree. >> This area is anchored in a percpu pointer and can be retrieved by any >> level of the dynamic entries. The normal way to handle allocation and >> freeing is to allocate the data in the enter() callback of a node and >> to free it in the related exit() callback. >> >> Add a hypfs_add_dyndir() function for adding a dynamic directory >> template to the tree, which is needed for having the correct reference >> to its position in hypfs. >> >> Signed-off-by: Juergen Gross >> --- >> V2: >> - switch to xzalloc_bytes() in hypfs_alloc_dyndata() (Jan Beulich) >> - carved out from previous patch >> - use enter() and exit() callbacks for allocating and freeing >> dyndata memory > > I can't seem to be able to spot what this describes, and the > respective part of the description therefore also remains unclear I think all pieces are coming together with patch 15. > to me. Not the least again when considering multi-level templates, > where potentially each of the handlers may want to allocate dyndata, > yet only one party can at a time. Right now: yes. In case needed it will be rather easy to have a linked list of dyndata entities, with the percpu dyndata variable pointing to the most recent one (the one of the currently deepest nesting level). > >> - add hypfs_add_dyndir() > > Overall this patch adds a lot of (for now) dead code, which makes it > hard to judge whether this is what's needed. I guess I'll again > learn more by reding further patches. I hope so.