Greg Haerr writes:
>
> : Bcc. I think that its one of the things that needs porting the most. Why?
> : Here's why.
> :
> : ELKS is shaping up quite nicely. We have a useable unixish system. But I
> : think that it needs certain things:
> :
> :
> : A C compiler.
>
> I have had as a top priority getting the dev86 kit (bcc, as86, ld86)
> to run on ELKS ever since I first found ELKS. I have spent considerable
> hours enhancing the bcc compiler (it now compiles ansi without a preprocessor,)
> and have got all the dev programs to build and link using bcc. I also ported
> a small ar86 just for ELKS. On running them,
> there are a number of difficulties. As86 dies for lack of memory thru the brk()
> system call, which doesn't seem to work yet. In addition, back in January,
> when I did all this work, the ELKS kernel would corrupt the filesystem after any
> unlink(), and there was no fsck. So I gave up, ported bcc etc to minix, and started
> compiling it's libc.
The unlink() problem is basically fixed I think. There is still a problem
if you unlink processes that never terminate (like init). fsck is close to
being ready. I will include it in the next version.
>
> ELKS now has come a long way, and I think that the filesystem works,
> fsck is available, and signals and pipes work, but we need people to run on it,
> and do stupid things that break things.
>
> I will volunteer to get all the tools self-hosting and produce a development
> distribution of them.
>
>
> : A nice(ish) way to install it. (ie, distribution)
>
> ELKS needs a distribution that allows the entire kernel and commands
> to be built, and then booted from, for hard disk usage. The chief maintainer,
> Al, only uses ELKS from floppy. We need more people testing ELKS using
> a standard command set compiled from scratch, and we need fsck in the distribution.
Not entirely true. I do install to HD every now again, but find it a bit
soul destroying as I crash so often it becomes unusable very quickly.
> In addition, the minix filesystem *must* support files > 512k, something it doesn't
>do
> now. The libc.a file is > 512k so you can't even link anything on ELKS. This
> requires supporting > 7 indirect blocks.
>
> I will volunteer to fix the 512k block limit, but I'd like someone to
> build a standard distribution, that includes all commands and kernel and
> allows *everything* to be built from the top with one "make all".
Okay, this is part of my overall goal, which I will be looking at overall.
'make all' will build all the binaries, make floppy will create a small
filesystem suitable for booting from, and then you will be able to create
packages which are tar files containing other binaries.
>
> In addition, being the chief nano-X contributor, I would like to see
> ELKS bundled with a nano-X distribution. I ported and maintain
> nano-X for ELKS, so I can help with this.
>
>
> : A decent text editor.
> Use levee for now, I've got a vi, but we need to actually
> try to use ELKS's filesystem, signals, and pipes before you'll want to edit
> anything for keeps.
>
> : Networking.
>
> I think we need ELKS DLL's for this, so that we can run the kernel and
> any user programs with separate code and data segments to keep the link
> size < 64k. Al has done work on shared libraries, and I have some ideas more
> akin to Windows real-mode linking, but we need mods to the development tools
> for this. I'll do them if you want.
>
> : Romability. (I think I just invented a new word! 8*)
> : More standard unix commands.
>
> Please make a list of commands you want. It would be nice
> to list the commands we have, and what doesn't work with them.
>
>
>
> : Protected mode stuff. (With Expanded memory support).
>
> We're a ways off from this, but it'd be nice. I'd like to see
> support for > 64k segments.
> :
> :
> : Some of these things will be difficult (if possible), but I think that
> : this is what we need to make it into a useable system. If people can use
> : the thing, then they are a lot more likely to work on it / test it.
>
> I totally agree. Pull down ELKS, and elkscmd, and compile them
> and run them and send comments to this list as to what works and what doesn't.
> Al said that he got signals working with the latest version, but I don't know
> what the number is or where to find it. The version that I last ran, 0.0.74,
> couldn't do "ls > file" or "ls | more" without dying or breaking the file system.
>
The default shell that root has when you log in is sash, which does not
support any of the above. If you 'exec /bin/ash', you then have a decent
shell with redirection and pipes which may work to an extent. I may now be
time to make ash the default shell, but it does have licensing issues.
Remember that you can get the latest CVS code either by checking out
anonymously from the CVS server, or by downloading the daily snapshots. See
section 4 of the FAQ for details.
Al
