[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 09/12] xen/hypfs: add support for id-based dynamic directories
On 17.11.2020 15:38, Jürgen Groß wrote: > On 17.11.20 14:33, Jan Beulich wrote: >> On 26.10.2020 10:13, Juergen Gross wrote: >>> +static struct hypfs_entry *hypfs_dyndir_findentry(struct hypfs_entry_dir >>> *dir, >>> + const char *name, >>> + unsigned int name_len) >>> +{ >>> + struct hypfs_dyndir_id *data; >>> + >>> + data = hypfs_get_dyndata(); >>> + if ( !data ) >>> + return ERR_PTR(-ENOENT); >>> + >>> + /* Use template with original findentry function. */ >>> + return data->template->e.funcs->findentry(data->template, name, >>> name_len); >> >> Why does this pass the address of the template? If it truly is >> (just) a template, then its dirlist ought to be empty at all >> times? If otoh the "template" indeed gets used as a node in the >> tree then perhaps it wants naming differently? "Stem" would come >> to mind, but likely there are better alternatives. I've also >> considered the German "Statthalter", but its English translations >> don't seem reasonable to me here. And "placeholder" has kind of a >> negative touch. (Also in this case some of my "const?" remarks >> may be irrelevant.) > > It is basically a template tree. > > In the current use case (cpupool/<id>/sched-gran) the template is > <id> with the leaf "sched-gran" which is the template for the per > cpupool incarnation. I can see sched-gran being a template, albeit even that will get dirtied as soon as a second leaf appears, as then these entries again need linking together. I think anything called template should be strictly r/o. It's also not clear to me how adding a 2nd level in the hierarchy would end up working: <component>/<id1>/<id2>/<leaf>. How would <leaf> know all the higher level IDs it's associated with? While I don't think this needs making work right away, the underlying model at least shouldn't prohibit it. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |