>Actually, I'd like a central compression library with a large
>assortment of algorithms. That way the really common code is shared
>between both (or more) projects is shared.
>
>Also, yet another unused compression algorithm hurts about as bad, as
>yet another unused device driver. It just grows the kernel .tar.bz2.
>
>J?rn
Had a thought. Why wait for a compression algorithm? Jorn, if you are going
to work on putting the code into the kernel and making the stuff to allow the
swap code to use it, why not start coding it before the compression code is
finished? i.e. get the stuff down for the swap filtering (filtering i.e. passing
through a compression or encryption routine) and swap-on-ram stuff, and later
take the compression algo code and place the module interface on it and make
a kernel module.
At this point, I'd say to allow specified order filters, to allow for swap cyphering
and compression. Security, you know; swap files are a security hazard. Just
power-off, boot a root disk, pull up the swap partition, rip out the blocks, and
look for what looks to be the root password.
--Bluefox Icy
On Thu, May 01, 2003 at 06:07:59PM -0400, rmoser wrote:
> Had a thought. Why wait for a compression algorithm? Jorn, if you are going
> to work on putting the code into the kernel and making the stuff to allow the
> swap code to use it, why not start coding it before the compression code is
> finished? i.e. get the stuff down for the swap filtering (filtering i.e. passing
> through a compression or encryption routine) and swap-on-ram stuff, and later
> take the compression algo code and place the module interface on it and make
> a kernel module.
>
> At this point, I'd say to allow specified order filters, to allow for swap cyphering
> and compression. Security, you know; swap files are a security hazard. Just
> power-off, boot a root disk, pull up the swap partition, rip out the blocks, and
> look for what looks to be the root password.
While we're having thoughts, this thread keeps me thinking
it would make sense to have a block device driver that would
be assigned unused memory.
I don't mean memory on video cards etc. I'm thinking of the
10% of RAM unused when 1GB systems are booted with MEM=900M
because they run faster with HIGHMEM turned off.
The primary use for this "device" would be high priority swap.
Even with whatever overhead it takes to access it should be
orders of magnitude faster than any spinning media.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt