Re: Sendkey patch

[Javier Martín]

El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió:
> Hello, again.
> Javier Martín wrote:
> > We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
> > first is used by the MBR).
> > 
> I've just rechecked on my system. My first partition begins at sector
> number 63. This is the value I've seen at most systems. So last usable
> sector is 62. Sector 0 is MBR. So we have 62 sectors
Oops, true! How strange. So there was no sector 63 in the CHS model and
that is why the first sector of cyl 1 (the start of the first partition)
is LBA 63... Does anyone know the historical reasons for this?

> >> 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).
> > 
> I'll have a look at it but not sure to find anything since I'm not
> familiar with either ata or reiserfs internal structure.
I was not suggesting that it was you or me who did it; it was a general
"call" for GRUB devs... (ahem xD)

> > 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.
> Well the point is that if we don't do it now and then one day we'll have
> to squeeze the core it will be very difficult to find places like this.
Yes, but my point is that 40 bytes is so small a difference that it can
offset by simply rewriting error strings in kernel and other smallish
non-intrusive changes and thus we should prioritize future
maintainability. However, eventually this is not our decision to make:
the Overlords here (mainly Marco, but also Robert, Vesa and Bean) are
the ones who should, likely only once the interface is established,
decide how to conjugate the Prime Directive of "keep kernel small" with
code complexity in this particular case.

-Habbit

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