Re: More dev86 changes (0.16.5)

[mjn3@codepoet.org (Manuel Novoa III)]

Paul,

On Wed, Jul 24, 2002 at 11:26:32PM +0100, Paul Nasrat wrote:
> I'd quite like to at least attempt to contribute to linux-86/elks libc.
> I've played with ucLibc and also dredged up some stuff in the cvs
> repostiory merged from dev86 but not in dev86 releases, and that confuses
> me...

A little bit of history... uC-libc was the libc put together by the
uClinux people.  It included a lot of dev86 code, but I think that's
where the connection ends.  More than 2 years ago, Erik Andersen forked
a version and renamed it uClibc.  His goal was to have a small libc to
use with busybox.

I got involved with uClibc almost 2 years ago... not long after Erik
had grafted on the glibc headers.  In that time, most of the original
dev86 code in uClibc has been modified or completely replaced.  Of the
current subdirs in uClibc, I've written much of stdlib and most or all
of the code in stdio, string, time, ctype, locale, wctype, and wchar.
Most of that code was written with eventual porting to elks/bcc in mind
and currently builds with the appropriate sys headers.  I'm hoping to
have elks/bcc support in uClibc in the next couple of months.

> It's moved since my last attempt to try and get involved (and failing
> due to slackness)
> 
> http://cvs.uclinux.org/cgi-bin/cvsweb/uClibc/libc/inet/addr.c?rev=1.1&content-type=text/x-cvsweb-markup

uclibc.org is the primary site for uClibc.

> I'd quite like to see dev86 with a cvs repository so I can look over
> different versions to learn about things.  I'd understand if you don't
> want to bother merging past stuff into a repostiory but just out of
> curiosity in terms of compiler stuff, libc stuff, and asm I'd like to
> be able to easily see the stuff you're doing.
> 
> I may not be good enough to contribute, but if you can at least cvs it,
> and give access to that, it'd be an education.

You might also want to look at the busybox cvs repository at busybox.net.
Certainly most of the busybox applets are far more featureful than
their elkscmd counterparts, and many should be easy enough to seperate
out and port to elks.

Manuel