binary size changes from 0.1.0

binary size changes from 0.1.0

[claudio]

I'm generating bootable images with current elks and I was
puzzled because the new files don't fit in the "root" image.
Comparing the binary sizes with the old images from 0.1.0,
I found the following:

File          New size    Old size    Delta
------------- --------- ----------- -------
ash             69900      59196      10704
cat              3940       1960       1980
chgrp            9700       7348       2352
chmod            6756       4408       2348
chown            8388       6020       2368
clock            7240       7528       -288
cmp              7384       5004       2380
cp               8720       6388       2332
exitemu           196        196          0
getty           10744       8364       2380
init             6516       6788       -272
kill             5108       2648       2460
login           11132       8844       2288
ls              16724      14632       2092
meminfo          6820       4456       2364
mkdir             940        956        -16
mknod            1528       1524          4
mount            4128       1620       2508
mv               6076       3568       2508
passwd          13888          0      13888
ps               8828       6444       2384
rm                572        588        -16
rmdir             844        860        -16
sh              69900      59196      10704
swapon           9648       7344       2304
sync              212        228        -16
touch             420        436        -16
umount           3772       1264       2508
------------- --------- ----------- -------

What could explain that difference? Is the new libc that
larger? Note that cat has only a bunch of syscalls.

Re: binary size changes from 0.1.0

[Gábor Lénárt]

Re,

Also if you check some simple utils, like chmod and others, you will see
that significant amount of size is error description, I mean textual
representation of errno codes, as you can get by calling perror() or
via sys_errlist array. The only problem that almost EACH utility has
to contain these messages. So, the best soultion would be shared library
of course but it's hard to implement at once. In my experimental OS
this was handled in quite "ugly" way: include messages into the kernel,
and let a syscall query the error message. This is very ugly, but it's
simple, and avoids each binary contain all of the messages, so it will
result in less memory usage, and of course smaller disk image ...

On Wed, Jun 09, 2004 at 03:55:42PM -0300, claudio@conectiva.com wrote:
> 
> I'm generating bootable images with current elks and I was
> puzzled because the new files don't fit in the "root" image.
> Comparing the binary sizes with the old images from 0.1.0,
> I found the following:
> 
> File          New size    Old size    Delta
> ------------- --------- ----------- -------
> ash             69900      59196      10704
> cat              3940       1960       1980
> chgrp            9700       7348       2352
> chmod            6756       4408       2348
> chown            8388       6020       2368
> clock            7240       7528       -288
> cmp              7384       5004       2380
> cp               8720       6388       2332
> exitemu           196        196          0
> getty           10744       8364       2380
> init             6516       6788       -272
> kill             5108       2648       2460
> login           11132       8844       2288
> ls              16724      14632       2092
> meminfo          6820       4456       2364
> mkdir             940        956        -16
> mknod            1528       1524          4
> mount            4128       1620       2508
> mv               6076       3568       2508
> passwd          13888          0      13888
> ps               8828       6444       2384
> rm                572        588        -16
> rmdir             844        860        -16
> sh              69900      59196      10704
> swapon           9648       7344       2304
> sync              212        228        -16
> touch             420        436        -16
> umount           3772       1264       2508
> ------------- --------- ----------- -------
> 
> What could explain that difference? Is the new libc that
> larger? Note that cat has only a bunch of syscalls.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: binary size changes from 0.1.0

[David Given]

On Thursday 10 June 2004 08:35, Gábor Lénárt wrote:
> Also if you check some simple utils, like chmod and others, you will see
> that significant amount of size is error description, I mean textual
> representation of errno codes, as you can get by calling perror() or
> via sys_errlist array. The only problem that almost EACH utility has
> to contain these messages. So, the best soultion would be shared library
> of course but it's hard to implement at once. In my experimental OS
> this was handled in quite "ugly" way: include messages into the kernel,
> and let a syscall query the error message. This is very ugly, but it's
> simple, and avoids each binary contain all of the messages, so it will
> result in less memory usage, and of course smaller disk image ...

One common trick is to not keep the list of error messages in memory at all, 
but to keep them in a file on disk. When perror() is called, the file is 
opened, read until the right error message is found, and that one used... of 
course, this approach means that you can't do sys_errlist, but it's perfectly 
adequate for perror.

You may also want to check to see if the optimisation settings have changed.

-- 
+- David Given --McQ-+ "Est brilgum: toui slimici
|  dg@cowlark.com    | In uabo tererotitant
| (dg@tao-group.com) | Brogoui sunt macresculi
+- www.cowlark.com --+ Momi rasti strugitant." --- Anonymous
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: binary size changes from 0.1.0

[Gábor Lénárt]

Re,

On Thu, Jun 10, 2004 at 10:52:50AM +0100, David Given wrote:
> On Thursday 10 June 2004 08:35, Gábor Lénárt wrote:
> > Also if you check some simple utils, like chmod and others, you will see
> > that significant amount of size is error description, I mean textual
> > representation of errno codes, as you can get by calling perror() or
> > via sys_errlist array. The only problem that almost EACH utility has
> > to contain these messages. So, the best soultion would be shared library
> > of course but it's hard to implement at once. In my experimental OS
> > this was handled in quite "ugly" way: include messages into the kernel,
> > and let a syscall query the error message. This is very ugly, but it's
> > simple, and avoids each binary contain all of the messages, so it will
> > result in less memory usage, and of course smaller disk image ...
> 
> One common trick is to not keep the list of error messages in memory at all, 
> but to keep them in a file on disk. When perror() is called, the file is 
> opened, read until the right error message is found, and that one used... of 
> course, this approach means that you can't do sys_errlist, but it's perfectly 
> adequate for perror.

Yes, this was my first reaction as well, but if the app make heavy usage of
getting error message, it would result in great amount of I/O (well, if
kernel dcache is working, it could be not a big problem altough), so I've
got this solution instead. Also, what's up if you delete /etc/syserr.list
(or whatever the file is placed). Also, you may have got eg kernel
filesystem let's say mounted under /kernel, and /kernel/syserr.list can be
seen by user space, and it's exported by the kernel. However this may be an
overcomplicated situation for an ELKS class OS (maybe not for a 32bit OS
though). However if ELKS would use this filsystem for other purposes as well
(like /proc/ in Linux, however this is ugly since process information and
others should be well separated), this can be considered.

However it's not about the original problem exactly, an external error
message file can be enough. Well, at least for me ;-)

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: binary size changes from 0.1.0

[Harry Kalogirou]

> One common trick is to not keep the list of error messages in memory at all, 
> but to keep them in a file on disk. When perror() is called, the file is 
> opened, read until the right error message is found, and that one used...

I think ELKS's libc does that... at least it used to do...

-- 
Harry Kalogirou <harkal@gmx.net>

Re: binary size changes from 0.1.0

[claudio]

On Fri, 11 Jun 2004, Harry Kalogirou wrote:

> > One common trick is to not keep the list of error messages in memory
> > but to keep them in a file on disk. When perror() is called, the file is
> > opened, read until the right error message is found, and that one used...
>
> I think ELKS's libc does that... at least it used to do...

It does that it you use -Mf to use the "small and fast" libc_f. The
default behaviour is to include the strings in every binary. This option
also changes the function call protocol. I made some tests and the
resulting binaries are significantly smaller, similar to those in the
0.1.0 disk images.