A practical use for MAP_FIXED

And one against every 'use recommendation' :->.

Part of the functionality of the strange appliances my employer builds
is scanning e-mails downloaded over POP3 for viruses etc. Presently,
this is done by antivir, which is a PITA, because it permanently grabs
40 of the 64M of RAM available on the units and most of the time just
sits there, doing nothing. Starting it on demand isn't an option
because of the enormously long time needed to fill those 40M with
'some search structure' constructed from the contents of the antivir
signature file. This cannot continue, because the program increases
its memory requirements by about 1M per month and this has to be
accepted as a law of nature, insofar the company producing this
software is concerned (I could write more on this but this would
probably be 'business internals' I may not talk about. But my life
will certainly get a lot more pleasant in the near future).

To solve this problem, the appliance OS will be switched to ClamAV
before next year. On a PC, the ClamAV scanning daemon presently
consumes 31M of RAM after it has constructed its 'search data
structure', presumably, in pretty much the same way the antivir daemon
does this, too. This is still more than what I would like it to be,
though. Therefore, I have written a fairly small (1155 LOC) program
which just writes all of the in-core data structures used by libclamav
to a memory mapped file (with some optimizations, like collecting all
strings in an area of their own after sorting them), modifying all
pointers used by them to be relative to a fixed 'base location'
available for mmap'ing such a file on an appliance. Creating a
squashfs out of this file yields a compressed output of about
11.6M. The scanning program to be used on the units (to be written,
although I have done a quick, hacky modification of clamscan as a
proof-of-concept) will then mmap this file into its address space,
using MAP_FIXED and the predetermined load address. Afterwards, it can
immediatly start to scan files, because the data structures needed for
doing so have already been constructed (on a much faster computer) and
the really nice thing about this is that nothing of the signature
database needs to be memory resident (it must live on the flash,
anyway), except insofar the kernel (2.4.35-based) has free pages
available to cache the decompressed contents of the squashfs hosting
the signature db.



.