[Openvas-devel] Changes to cache file handling
sgros.ml at gmail.com
Fri Jan 9 22:53:53 CET 2009
On Thu, Jan 8, 2009 at 1:21 AM, Jan-Oliver Wagner
<jan-oliver.wagner at intevation.de> wrote:
> Hello Stjepan,
> I've further analysed your API requirements for openvas-libraries.
> You introduced a "subdir" param for two functions of store.c.
> AFAIU, this subdir is the path between the cache_dir and the actual
> My changes to store_plugin and store_load_plugin
> allow to have arbitrary paths for filename. So you can
> combine subdir and filename when calling the function.
> (Perhaps use g_build_filename() for this).
I can't remember why I did this that way (i.e. that subdir is
separately handled). Probably there could be some optimization in
combining the subdir and filename. But, one of the possible problems,
as I remember, is that implicit include dir is subdirectory, relative
to a top level plugin directory, where plugin resides. If I combine
the two (filename and subdir) than I have a problem to get back subdir
in order to put it into a list of include directories.
> You should now be in the position to narrow down your patch
> in a way that you do not need to patch anything in openvas-libraries
> anymore (just use the latest SVN checkout).
> Next I will try to understand the concept of the include dirs list
> you have implemented.
> On Tuesday 06 January 2009 14:40:29 Stjepan Gros wrote:
>> On Sun, Jan 4, 2009 at 1:52 AM, Jan-Oliver Wagner
>> > I just comitted some further changes on the handling of cache files
>> > (.desc). It still needs some testing whether it works compatible with
>> > openvas-server 2.0.0 release. The main change is that the cache files now
>> > have different names (".desc" now appended, instead of replacing ".nasl"
>> > by ".desc").
>> This could cause slight compatibility problem (annoyance better to
>> say), not visible at first. Namely, existing cache with .desc will be
>> left and not deleted, while the new one will be created with
>> .nasl.desc extension. This should be taken care of during the upgrade.
> yes. This should also be explained in the release/announce text for the
> next version of openvas-libraries.
>> > In fact this is yet another patch that was derived from Stjepans patch
>> > for CR #24 (subdirs for plugins).
>> > Next planned patch is to finalize changes to openvas-libraries so
>> > that it allows for the new feature and can be released eventually as
>> > 2.0.1. Stjepans patch then extends to -libnasl and -server.
>> Should this be better versioned as 2.1 because the third numeral
>> usually means only bug fixes and minor changes?
> Well, there is no API change so far. So I thought, += 0.0.1 is OK ;-)
>> > The reason the progress is slow is that I had to do several cleanups of
>> > the code.
>> Well, I see this progresses well. :) There is one optimization when
>> cache is created that could be made. Namely, when plugin is loaded and
>> parsed then it's stored in cache and then reloaded. I have to see if
>> this reloading could be avoided. This will save one disk access (even
>> though it is cached by the OS).
> but this is outside of openvas-libraries, AFAIU.
> Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
> Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> Openvas-devel mailing list
> Openvas-devel at wald.intevation.org
More information about the Openvas-devel