Hi,
It seems svn is available at savannah:
https://savannah.gnu.org/forum/forum.php?forum_id=5340
any plan to switch ?
--
Bean
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
On Tue, Jun 17, 2008 at 10:47 AM, Javier Martín <[EMAIL PROTECTED]> wrote:
> El mar, 17-06-2008 a las 10:03 +0800, Bean escribió:
>> The decompresser is about 2K, we should also exclude the uncompressed
>> part at the beginning of kernel, but there is still plenty room left.
> The problem is not ju
El mar, 17-06-2008 a las 10:03 +0800, Bean escribió:
> The decompresser is about 2K, we should also exclude the uncompressed
> part at the beginning of kernel, but there is still plenty room left.
The problem is not just the decompresser size itself, but how much
memory it uses. LZO is pretty speci
On Tue, Jun 17, 2008 at 5:31 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 16, 2008 at 08:37:43PM +0800, Bean wrote:
>>
>> But do we really need those space ?
>
> The typical use case where space is a PITA is boot an LVM system without a
> separate /boot partition. There we don't have
On Mon, Jun 16, 2008 at 08:37:43PM +0800, Bean wrote:
>
> But do we really need those space ?
The typical use case where space is a PITA is boot an LVM system without a
separate /boot partition. There we don't have the ressort of using a
blocklist (which is already bad), so embedding core.img is
On Mon, Jun 16, 2008 at 01:20:27PM +0200, Javier Martín wrote:
> Hmm.. that could be done without too much fuss (except the part of
> implementing the decompressor in assembly for each platform...),
For other platforms than i386-pc, size is usually not a problem (well,
for coreboot it is, but ther
On Mon, Jun 16, 2008 at 07:03:50PM +0800, Bean wrote:
> On Mon, Jun 16, 2008 at 5:15 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> > On Mon, Jun 16, 2008 at 02:30:38PM +0800, Bean wrote:
> >>
> >> The fd and hd device share many code, separating them is not a good
> >> idea.
> >
> > If code duplic
On Mon, Jun 16, 2008 at 9:27 AM, Pavel Roskin <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-06-15 at 01:32 +0800, Bean wrote:
>
>> This patch revert ext2 and reiserfs driver to pre journal state. The
>> new journal support would be in a separate module and provide a
>> transparent mapping layer for the
Quoting Bean <[EMAIL PROTECTED]>:
On Mon, Jun 16, 2008 at 9:06 PM, Pavel Roskin <[EMAIL PROTECTED]> wrote:
No, it was uncompressed. GRUB 0.97 doesn't use LZO compression.
Yes, grub 0.97 don't use lzo, but I use external lzo tool to get the
result. It illustrates the result of lzo and lzma a
Quoting Bean <[EMAIL PROTECTED]>:
I see, you're using qemu to test ppc, maybe I can try it some time. Is
the emulation good, how close to the real hardware ?
qemu uses so called Open Hack'Ware, which doesn't have proper terminal
support for the menu and doesn't report available memory in the
On Mon, Jun 16, 2008 at 1:40 PM, Pavel Roskin <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-06-15 at 00:31 +0800, Bean wrote:
>
>> I test it with olpc and it works. I don't have ppc, would someone check it ?
>
> I could make CVS GRUB compile on PowerPC after removing floating point
> code, but I could
On Mon, Jun 16, 2008 at 9:06 PM, Pavel Roskin <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-06-16 at 14:09 +0200, Javier Martín wrote:
>> El lun, 16-06-2008 a las 19:47 +0800, Bean escribió:
>> > Well, I did some testing a while ago, the result is in:
>> >
>> > http://lists.gnu.org/archive/html/grub-de
On Mon, 2008-06-16 at 14:09 +0200, Javier Martín wrote:
> El lun, 16-06-2008 a las 19:47 +0800, Bean escribió:
> > Well, I did some testing a while ago, the result is in:
> >
> > http://lists.gnu.org/archive/html/grub-devel/2007-12/msg00114.html
> >
> > Even with lzo compressed image core.img, lz
On Mon, Jun 16, 2008 at 8:09 PM, Javier Martín <[EMAIL PROTECTED]> wrote:
> El lun, 16-06-2008 a las 19:47 +0800, Bean escribió:
>> Well, I did some testing a while ago, the result is in:
>>
>> http://lists.gnu.org/archive/html/grub-devel/2007-12/msg00114.html
>>
>> Even with lzo compressed image c
El lun, 16-06-2008 a las 19:47 +0800, Bean escribió:
> Well, I did some testing a while ago, the result is in:
>
> http://lists.gnu.org/archive/html/grub-devel/2007-12/msg00114.html
>
> Even with lzo compressed image core.img, lzma can save up to 5K.
>
You mean that even with an already compress
On Mon, Jun 16, 2008 at 7:20 PM, Javier Martín <[EMAIL PROTECTED]> wrote:
> El lun, 16-06-2008 a las 19:03 +0800, Bean escribió:
>> In that case, I suggest more dramatic
>> action, like replacing lzo with a strong compression algorithm, like
>> lzma, which would save a few thousand bytes.
>>
> Hmm.
El lun, 16-06-2008 a las 19:03 +0800, Bean escribió:
> In that case, I suggest more dramatic
> action, like replacing lzo with a strong compression algorithm, like
> lzma, which would save a few thousand bytes.
>
Hmm.. that could be done without too much fuss (except the part of
implementing the d
On Mon, Jun 16, 2008 at 5:15 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 16, 2008 at 02:30:38PM +0800, Bean wrote:
>>
>> The fd and hd device share many code, separating them is not a good
>> idea.
>
> If code duplication is a problem, we could link the same code staticaly for
> each
On Mon, Jun 16, 2008 at 02:30:38PM +0800, Bean wrote:
>
> The fd and hd device share many code, separating them is not a good
> idea.
If code duplication is a problem, we could link the same code staticaly for
each module. Size of biosdisk module is an issue, because it's always used
in core.img
19 matches
Mail list logo
