From: Harley Laue <losinggeneration@gmail.com>
To: linux-8086@vger.kernel.org
Subject: Re: ELKS CVS imported into Git with all history
Date: Wed, 8 Feb 2012 20:53:02 -0600 [thread overview]
Message-ID: <20120208205302.75524eea@arch-laptop> (raw)
In-Reply-To: <4F3199D9.5000304@jodybruchon.com>
On Tue, 07 Feb 2012 16:38:33 -0500
Jody Bruchon <jody@jodybruchon.com> wrote:
> On 02/07/12 09:49, Harley Laue wrote:
> > On 02/05/2012 11:14 PM, Jody wrote:
> >> Hello everyone on the ELKS list; check this out:
> >>
> >> http://elks.git.sourceforge.net/git/gitweb.cgi?p=elks/elks;a=summary
> >>
> >> Took me a few hours to get right, but there it is, for better or
> >> worse. You're welcome. ;-) Now I'm going to bed.
> >>
> >> Jody Bruchon
> > Just a curious question, is there a reason you decided to have
> > elks, elkscmd, and elksnet in the same repo instead of splitting
> > them into their own git repos?
> The simplest reason is that it was far easier to do it all in one
> shot (IOW: I'm lazy); additional thoughts include:
I can understand where you're coming from with that :)
> * It's all one big project (i.e. ELKS the kernel is useless without
> commands to run)
I've personally never found that a very compelling argument. The same
could be said about glibc, bash, etc to the Linux kernel. Having also
studying the BSD source repos, I'm not terribly against it either to be
honest.
> * It seems that these components are tightly tied to each other
> (really, what use is elkscmd without the ELKS kernel?)
Well, I was just able to compile sash, bc, byacc, & file_utils and run
them unaltered on an x86_64 Linux box. Granted some seem more tightly
tied in (ash, elvis, and rc I also tried without any luck.) I guess my
argument for this being split, if you want to call it an argument, is
this is more like busybox (or the GNU tools) and the kernel is its own
thing which may or may not use this as its interface. Basically the
kernel should be able to run any program the user may want, not
necessarily tied to elkscmd.
> * elksnet is minuscule and shouldn't have its own repository; if
> anything, I feel it should be merged into elkscmd.
Agreed. Probably elksutils would be a candidate to merge in as well.
> * I'm a minimalist and a pragmatist, and while the command sources
> should be split from the kernel sources, I see no reason to dump them
> into different repos; without an obvious and practical good reason to
> add that extra complication, I won't.
I did this back in 2009 with and it was only four commands to export
each partial repo. (One for elks, elkscmd, elksnet, & elksutils.)
*shrugs*
> Of course, if I'm wrong in that choice, we should talk about why.
> Honestly, at this stage, ELKS is in very real danger of dropping into
> irrelevance and left to rot forever. I could care less if every
> command had its own git repo, so long as people are working on the
> project!
I completely agree that I'd love to see people working on the project
above all else. I just thought I'd bring this up at an early stage so
if needed/wanted it could still be easily changed without much hassle
to anyone who's still interested in the source.
> Additionally, I'd like to assemble a list of open-source compilers
> that can build for 8086 and either are targeted to other 16-bit CPUs
> or can be relatively easily retargeted (I use that term loosely with
> compilers. If anyone has suggestions for alternative compilers,
> please email me with them, and I'll build a list and examine the
> merits of each against the others. The only ones I know of are tcc
> (by Fabrice Bellard), SDCC (targets Z80 but maybe we can retarget
> it)...and the venerable Bruce's C Compiler (bcc) which we already
> use. I dug up the original (non-Dev86) source for it and the 6809
> target parts are in that version, so maybe I can figure out how to
> retarget it if I can dig up a 6809 emulator somewhere.
SDCC may be an option, but it would need quite a bit of work to do the
retarget. I've used this compiler for the Z80 and it works quite well
and is the only one of the three mentioned that is still actively
maintained/updated (and supports a few other 8 & 16 bit processors.)
Another possibility might be to add 8086 support to LLVM. I doubt LLVM
would be interested in having the support built in, but SDCC may
actually accept patches to target 8086-80286 processors. Another
possibility that looks to already support i86 is ACK (The Amsterdam
Compiler Kit.) It looks to be pretty up-to-date and maintained as well.
prev parent reply other threads:[~2012-02-09 2:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-06 5:14 ELKS CVS imported into Git with all history Jody
2012-02-06 11:48 ` howto start kqt4at5v
[not found] ` <4F30291D.5030908@telia.com>
2012-02-07 12:08 ` kqt4at5v
2012-02-07 14:06 ` Jody
2012-02-07 14:46 ` David Given
[not found] ` <CAMKR1ysKw2SaGObU38Gv8Sh1GMkxjRRkc7wwNPvNDKAa7Z=0pw@mail.gmail.com>
2012-02-07 16:29 ` David Given
2012-02-07 18:48 ` kqt4at5v
2012-02-07 20:02 ` kqt4at5v
2012-02-07 14:49 ` ELKS CVS imported into Git with all history Harley Laue
2012-02-07 21:38 ` Jody Bruchon
2012-02-08 0:15 ` David Given
2012-02-08 2:56 ` Kirn Gill
2012-02-08 21:28 ` Juan Perez-Sanchez
2012-02-09 2:53 ` Harley Laue [this message]
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=20120208205302.75524eea@arch-laptop \
--to=losinggeneration@gmail.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).