debxo 0.3 release

[david at lang.hm]

On Sun, 2 Nov 2008, John Gilmore wrote:

>> things that I can see as possibly needed:
>> hardware encryption engine (does this show up to the kernel as an
>> available encryption device? (it would be handy if at least the
>> development builds of the kernel enabled /proc/config.gz for all xo
>> distros (including the OLPC builds) it costs about 10k
>> compressed, 40k raw)
>
> The Geode hardware encryption engine is useless for Unix user
> programs.  It was apparently designed for/by hardware engineers who
> had no idea how an operating system or a crypto library works.  It can
> only be accessed via DMA using physical addresses, which means a user
> program that wanted to do AES would have to do a kernel call and the
> kernel would have to copy the data to reside in contiguous physical
> memory, then copy the results back and return to user space.  It's
> much faster to simply do AES in software for virtually every
> application (and that software's already coded and tested).  If the
> Geode designers had only made the engine accessible via unprivileged
> instructions that took operands from registers or virtual memory, we'd
> have seen a very different result.

what about the kernel encryption modules? those aren't suitable for a lot 
of userspace code, but for other things (like network encryption where 
they kernel is already processing the data) can the CPU support 
replace/supplement the software versions?

>> is there anything else that may need special handling?
>
> Suspend/resume, e.g. when you close the lid.

the lid buttons handle detection of closing the lid

for suspend/resume what special cases are needed? or are you just saying 
that we need to check the suspend/resume support for all the hardware and 
make sure it's in the upstream kernel (and test it regularly so that they 
don't make a change that breaks it)?

David Lang