Re: Sendkey patch

[phcoder]

Javier Martín wrote:
> 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?
> 
int 0x13:0x08 can't return more than 63 sectors per track.
http://en.wikipedia.org/wiki/Int_13h#INT_13h_AH.3D08h:_Read_Drive_Parameters
>> 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)
> 
I understand. I was saying that I'll just have a look at least to know
what I'm talking about. But even if we manage to decrease the size of
reiserfs module there are still other FS which could result in big
modules e.g. ZFS.
>>> 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

40 bytes are small but 40 bytes per small interface is a big 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.
> 
You have the point. But if we don't discuss this matter the choice made
by maintainers can be random.
> -Habbit

Vladimir 'phcoder' Serbinenko