Dilyan Palauzov wrote: > Hello, > > Scanning memory regions: > > I was wondering if in libclamav there are some intentions to > introduce a function that scans data in memory, something similar to >
That can only be done, if all scan functions in libclamav are tought to scan mmap-ed areas (some already know how to do that) Its not just the matter of adding an API for scanning memory buffers. I think most of work would need to be done for scanning archives, where we extract files one-by-one, and scan them. I think you want to avoid temporary files in this case too? > cl_scanfile and cl_scandesc, but that does not have knowledge about > files. The intention is that if the file data is already loaded in the > memory, but is not on the disk, it will be simply faster to use (let me > call it) cl_scanmem(size_t datasize, void* data, char **virname,...) to > scan the data, instead of storing it to the disk. This will initially > simplify clamd/scanner.c: scanstream . Next to that I want to write an > For which MTA? > MTA plugin. It gets the mail-data from the MTA, and so that after the > data is transferred for cheking, there is in my case a pointer to the > data in memory, but no corresponding file. if you want to do all scanning in memory, you'll have to at least avoid temporary files to be created for attachments to mails, otherwise you won't see much of an improvement. Do you have a solution in mind, that wouldn't require significant changes in libclamav? > I consider it will be faster, > if such data can be scanned directly in the memory with a new function, > rather than storing it first to a file, and then calling the current > cl_scan... functions. > Did you try using tmpfs for /tmp? How much faster would it be than using tmpfs for /tmp? Having said that, I think that patches are welcome in this direction, but please show some comparison of the current speed vs. speed with your patch. > Automatic (API-transparent) notifications about DB updates: > > Have you considered using inotify (see > linux-source/filesystems/inotify.txt, in kernels newer than 2.6.12.6), > That is Linux specific, and IMHO it wouldn't offer a significant improvement. > to abolish the need for the user to call the cl_stat... functions (in > the custom case, when include/linux/inotify.h is available)? > Freshclam can notify clamd directly when an update has been done. Best regards, Edwin _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
