Re: ELKS disk images updated

Re: ELKS disk images updated

[Jody Bruchon]

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

Re: ELKS disk images updated

[Alan Carvalho de Assis]

On 2/19/12, Jody Bruchon <jody@jodybruchon.com> wrote:
snip
> 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.

Yes, you are right, modifying existent programs source code to become
just a single binary like busybox will be easier than porting original
busybox to ELKS.

Do you think it is easy to port Linux applications to use Dev86 libc
or is it very inconsistent?

> 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! :-)
>

I noticed some commands are not working correctly, please try this one:
# cd /bin
# ls -l | more

I think the problem is on pipe (|) because "more file" is working.

Thank you very much!

Best Regards,

Alan

Re: ELKS disk images updated

[Alan Carvalho de Assis]

Hi Jody,

It worked fine on QEMU ($ qemu -fda full3 -no-fd-bootchk)

Nice to see ELKS bringing back to life.

Do you think it is possible to port busybox (and uClibc) to 8086?

I noticed which summing up just the binaries bigger than 8000 bytes it
is more than 300KB :

ash 50652
banner 8396
ed 13092
getty 8156
install 14336
ktcp 22148
login 8556
ls 14196
man 15736
passwd 11344
proto 12228
remsync 20096
sash 9792
sh 50652 (symbolic link to ash ?)
stty 16148
synctree 18420
tar 8864
telnet 11036
tget 9276
urlget 12376
vi 34980
xargs 8320

Using busybox we could get a complete system (with even more programs)
in less than 300KB.

Best Regards,

Alan

On 2/19/12, Jody Bruchon <jody@jodybruchon.com> wrote:
> I have taken the liberty of updating the ELKS disk images to include the
> shiny new 0.1.4 kernel. I have also noticed many very strange bugs
> leading to infinite loops or locking myself out of the system (at least
> in QEMU). These can be fixed down the road. I am also going to try to
> disassemble the MINIX boot files at some point, since the only boot
> loader source we have is the bootsect.S in the kernel tree, which is
> useless if you want to load from a filesystem and not just dump the
> kernel straight to the disk. Also, note that the floppy signature for
> larger disk images is not present, so for QEMU in particular, you must
> specify the -no-fd-bootchk option. Once I disassemble the boot code
> (don't have time to do it right now), I'll fix this problem as well.
>
> Anyway, have a look at the disk images:
> https://sourceforge.net/projects/elks/files/ELKS%20Disk%20Images/0.1.4/
>
> Jody Bruchon
> --
> 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
>

ELKS disk images updated

[Jody Bruchon]

I have taken the liberty of updating the ELKS disk images to include the 
shiny new 0.1.4 kernel. I have also noticed many very strange bugs 
leading to infinite loops or locking myself out of the system (at least 
in QEMU). These can be fixed down the road. I am also going to try to 
disassemble the MINIX boot files at some point, since the only boot 
loader source we have is the bootsect.S in the kernel tree, which is 
useless if you want to load from a filesystem and not just dump the 
kernel straight to the disk. Also, note that the floppy signature for 
larger disk images is not present, so for QEMU in particular, you must 
specify the -no-fd-bootchk option. Once I disassemble the boot code 
(don't have time to do it right now), I'll fix this problem as well.

Anyway, have a look at the disk images:
https://sourceforge.net/projects/elks/files/ELKS%20Disk%20Images/0.1.4/

Jody Bruchon