From: "Javier Martín" <lordhabbit@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Sendkey patch
Date: Wed, 03 Sep 2008 01:38:02 +0200 [thread overview]
Message-ID: <1220398682.23879.70.camel@localhost> (raw)
In-Reply-To: <48BDBC96.3010602@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]
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 #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
next prev parent reply other threads:[~2008-09-02 23:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-02 14:23 Sendkey patch phcoder
2008-09-02 14:54 ` Javier Martín
2008-09-02 15:58 ` phcoder
2008-09-02 16:12 ` phcoder
2008-09-02 16:19 ` Vesa Jääskeläinen
2008-09-02 19:01 ` phcoder
2008-09-02 19:29 ` Vesa Jääskeläinen
2008-09-02 16:30 ` Javier Martín
2008-09-02 18:39 ` phcoder
2008-09-02 20:10 ` Javier Martín
2008-09-02 22:22 ` phcoder
2008-09-02 23:38 ` Javier Martín [this message]
2008-09-03 0:08 ` phcoder
2008-09-03 0:54 ` Javier Martín
2008-09-03 9:10 ` phcoder
2008-09-03 11:19 ` Javier Martín
2008-09-03 10:37 ` bitbucket
2008-09-03 7:07 ` Felix Zielcke
2008-09-03 17:07 ` Vesa Jääskeläinen
2008-09-03 17:23 ` Javier Martín
2008-09-03 17:25 ` Felix Zielcke
2008-09-03 17:48 ` phcoder
2008-09-03 17:53 ` Vesa Jääskeläinen
2008-09-03 18:11 ` phcoder
2008-09-04 22:16 ` Javier Martín
2008-09-05 16:13 ` [PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch) phcoder
2008-09-05 16:47 ` Javier Martín
2008-09-08 19:48 ` Vesa Jääskeläinen
2008-09-08 20:11 ` Javier Martín
2008-09-08 20:25 ` Vesa Jääskeläinen
2008-09-08 20:59 ` Javier Martín
2008-12-15 13:54 ` phcoder
2008-12-15 16:41 ` Vesa Jääskeläinen
2008-12-16 14:34 ` phcoder
2009-02-07 19:26 ` Robert Millan
2009-02-07 19:30 ` Robert Millan
2009-02-07 23:02 ` phcoder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1220398682.23879.70.camel@localhost \
--to=lordhabbit@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.