From: Jody Bruchon <jody@jodybruchon.com>
To: linux-8086@vger.kernel.org
Subject: Re: ELKS disk images updated
Date: Sun, 19 Feb 2012 13:57:24 -0500 [thread overview]
Message-ID: <4F414614.3010609@jodybruchon.com> (raw)
In-Reply-To: <4F41458F.9030506@jodybruchon.com>
On 2/19/2012 1:20 PM, Alan Carvalho de Assis wrote:
> Do you think it is possible to port busybox (and uClibc) to 8086?
We don't require uClibc, since the 8086 libc that comes with Dev86 is
probably even smaller. 32+-bit centric C libraries are extremely
unlikely to play nicely with ELKS; consider that the libc.so for a
typical i386 uClibc is hundreds of KiB, which is way too fat for ELKS.
The biggest problem with porting any software to ELKS is that the final
binary's .text segment absolutely must be less than 64 KiB in size, with
the secondary problem being that ELKS doesn't support many of the modern
libraries and interfaces that are used by other projects.
BusyBox would be FANTASTIC to port to ELKS, and you're correct that it
would drastically shrink the size of the binaries. Unfortunately,
BusyBox is also massive by ELKS standards. Note that ELKS "ls" has no
help text and is lacking many features; other binaries are the same.
Everything we currently use is a heavily stripped down version often
derived from code that is well over 10 years old, plus we are restricted
to a dialect of C that will no doubt require some extra rewriting to
conform to. I feel that a much better approach will be to take the
separate sources we have now and combine them into an ELKS "BusyBox"
instead. It would involve far less work since the tools work fine with
ELKS already and are written in the C dialect required. I'll take
another look and see what I could do to merge them together.
> I noticed which summing up just the binaries bigger than 8000 bytes it
> is more than 300KB :
sh is a copy of ash, not a symlink, unless you use the 360K root disk,
where I symlinked it and was able to copy a few more useful tools such
as "tr" because of the extra 50K I gained. I will correct that problem
later; the other disks had free space whereas the 360K root disk was
totally full. When I built new binaries with the latest Dev86 toolchain,
all binaries shrunk, so I took advantage of this to further reduce the
size of the system. The 360K disk is still completely full...but now it
has more stuff! :-)
Jody Bruchon
next parent reply other threads:[~2012-02-19 18:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4F41458F.9030506@jodybruchon.com>
2012-02-19 18:57 ` Jody Bruchon [this message]
2012-02-19 23:12 ` ELKS disk images updated Alan Carvalho de Assis
2012-02-19 18:20 Alan Carvalho de Assis
-- strict thread matches above, loose matches on Subject: below --
2012-02-19 17:09 Jody Bruchon
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=4F414614.3010609@jodybruchon.com \
--to=jody@jodybruchon.com \
--cc=linux-8086@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).