As I already stated on the IRC libgcrypt modules are optimized for speed
and not the performance (e.g. main loop of sha1 is repeated multiple
times with minor modifications to avoid if's). Generally it's ok to
optimize for speed but in context of embedding size is more important.
On the other h
Michael Gorven wrote:
On Tuesday 31 March 2009 10:50:57 phcoder wrote:
How big is your core.img?
With the following modules (untested), 61K.
configfile sha1 biosdisk pc linux ext2 minicmd crypto aes luks sha256
You don't need to embed linux.mod to the kernel, it can very weel be
loaded from e
On Tuesday 31 March 2009 10:50:57 phcoder wrote:
> How big is your core.img?
With the following modules (untested), 61K.
configfile sha1 biosdisk pc linux ext2 minicmd crypto aes luks sha256
--
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E
signature.asc
Description: T
Michael Gorven wrote:
On Tuesday 31 March 2009 09:50:17 phcoder wrote:
Michael Gorven wrote:
On Tuesday 31 March 2009 04:48:02 steve wrote:
Update, i was able to get the right modules to load into a core.img by
making the encrypted partition start at 1mb instead of 32.5kb, the
modules loaded i
On Tuesday 31 March 2009 09:50:17 phcoder wrote:
> Michael Gorven wrote:
> > On Tuesday 31 March 2009 04:48:02 steve wrote:
> >> Update, i was able to get the right modules to load into a core.img by
> >> making the encrypted partition start at 1mb instead of 32.5kb, the
> >> modules loaded into co
Michael Gorven wrote:
On Tuesday 31 March 2009 04:48:02 steve wrote:
Update, i was able to get the right modules to load into a core.img by
making the encrypted partition start at 1mb instead of 32.5kb, the modules
loaded into core.img were:
Nice! I briefly looked at getting everything into co
On Tuesday 31 March 2009 04:48:02 steve wrote:
> Update, i was able to get the right modules to load into a core.img by
> making the encrypted partition start at 1mb instead of 32.5kb, the modules
> loaded into core.img were:
Nice! I briefly looked at getting everything into core.img, but it seeme
Update, i was able to get the right modules to load into a core.img by
making the encrypted partition start at 1mb instead of 32.5kb, the modules
loaded into core.img were:
configfile sha1 fs_uuid biosdisk pc linux ext2 help minicmd crypto aes luks
sha256 devmapper
At boot, i issue the ls command
Thank you very much. The source builds and seems to function fine, I did
some experimentation loading the necessary crypto modules directly into
core.img but i believe i hit either a size limit or some other unknown
problem, so i loaded the bare necessity of minicmd, ext2, biosdisk and pc
and had i
On Sunday 29 March 2009 21:54:54 steve wrote:
> Whatever is easier for you, though a repo would be easier for me.
I've published the repo at http://michael.gorven.za.net/hg/grub/luks. I merged
with trunk this morning and fixed some compilation errors, but haven't
actually tested it yet so it mig
Whatever is easier for you, though a repo would be easier for me.
I have not used mailing lists before, so apologies if this message does not
appear correctly in the thread.
Thanks,
Steve
Xerces Partners
>
> I still need to get round to sorting out my copyright assignment and
> cleaning
The co
On Sunday 29 March 2009 00:52:43 steve wrote:
> I have been following the past conversations about support for cryptoroot
> and LUKS in grub2, concerning various patches and licensing issues, and i
> would like to know what is the current status of the development process?
> Is there a separate dev
I have been following the past conversations about support for cryptoroot
and LUKS in grub2, concerning various patches and licensing issues, and i
would like to know what is the current status of the development process? Is
there a separate development tree i should be pulling the code from for
te
13 matches
Mail list logo
