grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sendkey patch


From: Javier Martín
Subject: Re: Sendkey patch
Date: Wed, 03 Sep 2008 01:38:02 +0200

El mié, 03-09-2008 a las 00:22 +0200, phcoder escribió:
> > Here is my "version" of your patch, without the double indirection and
> > the strange plays. The overhead is 103 bytes without the error line
> > against 63 of yours, but I really think that the symmetric and
> > understandable handling of previous and next is worth 40 bytes.
> > 
> Well let's summ up what we have:
> -my version in 63 bytes but difficult to read (could some comments help
> with it?)
> -your version much easier to read but in 103 bytes
> Neither of versions is right or wrong. It's a question of priorities. I
> had some experiences that past some point it's difficult to decrease
> size past some point. Core image has to be embed in first cylinder.
> There we have 62 sectors=31744 bytes.
We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
first is used by the MBR).

> And now our core image (my version
> with error reporting) with ata,pc  and reiserfs is 29654 bytes. This
> leaves us 2090 bytes. This combination is not something completely out
> of the ordinary. So I suggest to give the priority to the size of the
> kernel over readability (perhaps adding some comments to my version).
I was wondering why my data did not match yours, and then I realized I
was using my usual "extreme" combination of modules: "biosdisk pc ext2
lvm raid" yields 29298 bytes, "plenty" of space. But ata and reiserfs
are quite the bloaters... The reiserfs case is particularly strange: in
the linux kernel, the reiserfs module is 50% bigger than ext3.ko; while
in GRUB, reiserfs.mod (without journaling) is twice the size of ext2.mod
(which includes full support for ext2, partial journal support in ext3
and extents in ext4).

Thus, while you are right in prioritizing kernel size; why not optimize
reiserfs a bit instead of killing our (and future maintainers') eyes and
brains to shave less than 40 bytes from kernel? I suppose the story
would be similar with ata, because it is a new module that is yet in
development.

-Habbit

Attachment: signature.asc
Description: Esta parte del mensaje está firmada digitalmente


reply via email to

[Prev in Thread] Current Thread [Next in Thread]