On Sun, Dec 14, 2008 at 9:58 PM, Jan-Oliver Wagner <jan-oliver.wag...@intevation.de> wrote: > On Sunday 14 December 2008 11:37:48 Stjepan Gros wrote: >> It turns out that the function plug_get_oid returns numerical values >> (in a string) for all the plugins, so maybe numerical values should be >> used consistently with symbolic names (if necessary at all) being soft >> links to numercal values. > > AFAIU, the OID numerical values are the ones that count. > >> >> > I propose a careful step-by-step implementation. >> >> > For example, moving the caching into a separate directory would be a >> >> > first nice step. There, it could already be realized to have a >> >> > directory strucure based on the OIDs of the NVTs. >> >> >> >> This idea is fine with me. I could split patch so that only cache is >> >> changed. This could be first iteration. What is not implemented is >> >> storing plugins according to OID and to try to implement that part >> >> would be the second iteration. >> > >> > that would be just perfect. >> >> Ok, I started to work on this but stumbled on a problem at a very >> start. :) Apart from the questions I sent in another mail (they are >> general enough and do not influence so much the cache reoganization) >> there is one bigger problem to OID organization of the plugins. >> >> Currently, the code functions in such a way that it starts with the >> name of the plugin and then searches for this name in the cache >> directory. If it's found then checks are made to determine if the >> cache is current or not followed by other processing. >> >> Now, the idea is to also start with a name but then to look it into >> the cache _by OID_. But the OID is not known until the source of the >> plugin is loaded and parsed, which beats the idea of the cache. >> >> The possible solution is to pelaod the cache, and than to start >> loading the sources. Then, the cache can be searched by the full >> pathname. There are two ways in which this can be implemented: > > Wouldn't another solution option be to reorganize the caching as such > to be based on OIDs instead of names?
That is the idea. The problem is that plugins themselves, as source files, are stored in files with descriptive names. Now, when you know the name of the plugin on a disk, you don't know it's OID until you read and parse it. For easier understanding I'll describe this process now, and how it is planned to be implemented, on a plugin named plugin.nasl with an OID 1.2.3.4.5.6.7.8 Current code --------------- Upon openvasd startup it takes plugin, plugin.nasl, loads and parses it and then stores it's cache into PLUGINDIR/.desc/plugin.desc On each other invocation, for a plugin named plugin.nasl, before loading source and parsing it, it loads PLUGINDIR/.desc/plugin.desc (name which is easily constructed from the plugin's name ONLY!) and then checks timestamps on the files to determine if the cache has to be updates. Planned code ---------------- Upon openvasd startup it takes plugin, plugin.nasl, loads and parses it and then stores it's cache into CACHEDIR/1/2/3/4/5/6/7/8/plugin.desc (or something similar). But, on each other invocation, for a plugin named plugin.nasl there is no way for openvasd to know OID, if the plugin.nasl itself is not loaded and parsed and thus, it can not check if there is (for a start) file CACHEDIR/1/2/3/4/5/6/7/8/plugin.desc (or something similar) nor if the source is newer than the cache. Did I better explain the problem? > >> What are opinions of the people on this list about this? > > I am not 100% sure I understood you proposed solution options. > Preloading seems to me (at a very first glance) quite complicated. > I confess I did not dig into this code path, but wouldn't it be possible > to build the cache in a way that the key for searching is the OID? > >> P.S. Should I update CR with this information? > > Sure, CRs are living documents. You may update them whenever it > makes sense. Ok, I'll update it when we reach some consensus about this. Stjepan _______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
