From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jody Bruchon Subject: Re: ELKS CVS imported into Git with all history Date: Tue, 07 Feb 2012 16:38:33 -0500 Message-ID: <4F3199D9.5000304@jodybruchon.com> References: <4F2F619A.7000608@jodybruchon.com> <4F313A09.70008@gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F313A09.70008@gmail.com> Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-8086@vger.kernel.org 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: * It's all one big project (i.e. ELKS the kernel is useless without commands to run) * It seems that these components are tightly tied to each other (really, what use is elkscmd without the ELKS kernel?) * elksnet is minuscule and shouldn't have its own repository; if anything, I feel it should be merged into elkscmd. * 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. 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! 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. Jody Bruchon